Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #153085 > unrolled thread
| Started by | hancock4@bbs.cpcn.com |
|---|---|
| First post | 2015-10-19 11:57 -0700 |
| Last post | 2015-10-24 07:03 +0000 |
| Articles | 20 on this page of 176 — 34 participants |
Back to article view | Back to alt.folklore.computers
the FORTH computer language hancock4@bbs.cpcn.com - 2015-10-19 11:57 -0700
Re: the FORTH computer language mentificium@gmail.com - 2015-10-20 05:05 -0700
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-20 13:57 -0400
Re: the FORTH computer language Daiyu Hurst <daiyu.hurst@gmail.com> - 2015-10-24 21:26 -0700
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-25 10:17 +0000
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-25 18:13 -0500
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-25 21:35 -0400
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-26 14:28 -0500
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-26 17:46 -0400
Re: the FORTH computer language Peter Flass <peter_flass@yahoo.com> - 2015-10-26 17:49 -0400
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:29 -0500
Re: the FORTH computer language Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-27 19:55 +0000
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-21 11:45 +0100
Re: the FORTH computer language Whiskers <catwheezel@operamail.com> - 2015-10-21 12:34 +0000
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-21 14:36 +0100
Re: the FORTH computer language David Hume <David.Hume@example.com> - 2015-10-22 09:38 +0100
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-22 11:07 +0100
Re: the FORTH computer language David Hume <David.Hume@example.com> - 2015-10-22 11:35 +0100
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-22 12:26 +0100
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-23 21:52 +0100
Re: the FORTH computer language David Hume <David.Hume@example.com> - 2015-10-23 23:16 +0100
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-24 00:21 +0100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-24 13:23 +0000
Re: the FORTH computer language Stan Barr <plan.b@bluesomatic.org> - 2015-10-24 15:25 +0000
Re: the FORTH computer language Morten Reistad <first@last.name.invalid> - 2015-10-24 22:37 +0200
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-25 13:30 +0000
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-25 13:30 +0000
Re: the FORTH computer language Stan Barr <plan.b@bluesomatic.org> - 2015-10-25 15:53 +0000
Re: the FORTH computer language Stan Barr <plan.b@bluesomatic.org> - 2015-10-25 16:08 +0000
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-26 12:08 +0000
Re: the FORTH computer language Stan Barr <plan.b@bluesomatic.org> - 2015-10-26 16:24 +0000
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-24 16:26 +0100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-25 13:30 +0000
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-25 16:33 +0000
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-26 12:03 +0000
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 06:49 -0700
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 07:02 -0700
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 07:18 -0700
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 07:28 -0700
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 07:39 -0700
Re: the FORTH computer language pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-26 16:25 +0000
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-26 14:36 -0500
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-26 17:41 -0400
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:26 -0500
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-27 22:47 -0400
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-27 12:22 +0000
Re: the FORTH computer language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-27 09:03 -0600
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:38 -0500
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-27 08:43 -0700
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:43 -0500
Re: the FORTH computer language hankvc@blackhole.lostwells.org (Hank) - 2015-10-28 19:05 +0000
Re: the FORTH computer language "78lp" <78lp@nospam.com> - 2015-10-28 16:08 +1100
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-28 05:43 -0700
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:37 -0500
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-27 18:48 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-28 12:58 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-28 08:15 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 08:37 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-30 04:58 +1100
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 12:19 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-28 12:58 +0000
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-28 11:08 -0700
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-28 18:46 +0000
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-28 17:58 -0400
Re: the FORTH computer language David Hume <David.Hume@example.com> - 2015-10-28 22:04 +0000
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-28 17:39 -0500
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-29 00:13 -0400
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-28 22:52 -0600
Re: the FORTH computer language "78lp" <78lp@nospam.com> - 2015-10-29 15:54 +1100
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-28 16:47 -0600
Re: the FORTH computer language Walter Bushell <proto@panix.com> - 2015-11-04 12:04 -0500
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-29 05:54 +1100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-29 07:21 -0700
Re: the FORTH computer language Andrew Swallow <am.swallow@btinternet.com> - 2015-10-29 16:48 +0000
Re: the FORTH computer language JimP <solosam90@gmail.com> - 2015-10-29 14:47 -0500
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-29 15:09 -0700
Re: the FORTH computer language Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-29 17:19 +0000
Re: the FORTH computer language Greymaus <mausg@mail.com> - 2015-10-29 18:18 +0000
Re: the FORTH computer language Ahem A Rivet's Shot <steveo@eircom.net> - 2015-10-29 18:02 +0000
Re: the FORTH computer language Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-29 19:37 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 11:28 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 08:42 -0600
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-29 14:49 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 08:57 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-30 08:39 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-31 13:22 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-31 09:36 -0600
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-31 09:47 -0700
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-11-01 15:14 +1100
Re: the FORTH computer language David Wade <dave.g4ugm@gmail.com> - 2015-11-01 16:38 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-11-02 12:58 +1100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-11-02 13:17 +0000
Re: the FORTH computer language "Osmium" <r124c4u102@comcast.net> - 2015-11-02 10:05 -0600
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-31 15:23 +1100
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 08:44 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language hancock4@bbs.cpcn.com - 2015-10-30 12:25 -0700
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-31 13:22 +0000
Re: the FORTH computer language David Wade <dave.g4ugm@gmail.com> - 2015-11-01 16:32 +0000
Re: the FORTH computer language "Osmium" <r124c4u102@comcast.net> - 2015-11-01 11:03 -0600
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-11-01 12:48 -0500
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-11-02 13:17 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-11-03 07:16 +1100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-11-03 12:55 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-11-04 08:07 +1100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-11-04 13:52 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-11-05 08:52 +1100
Re: the FORTH computer language Morten Reistad <first@last.name.invalid> - 2015-11-05 07:48 +0100
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-11-06 06:31 +1100
Re: the FORTH computer language hancock4@bbs.cpcn.com - 2015-11-02 07:34 -0800
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-11-01 23:55 -0800
Re: the FORTH computer language hancock4@bbs.cpcn.com - 2015-11-02 07:40 -0800
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-11-02 14:59 -0600
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-30 05:08 +1100
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-28 13:15 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
Re: the FORTH computer language Andrew Swallow <am.swallow@btinternet.com> - 2015-10-29 16:47 +0000
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-29 07:29 -0700
Re: the FORTH computer language "gareth" <no.spam@thank.you.invalid> - 2015-10-29 14:47 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 08:53 -0600
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-29 15:24 -0500
Re: the FORTH computer language scott@slp53.sl.home (Scott Lurndal) - 2015-10-28 13:20 +0000
Re: the FORTH computer language hankvc@blackhole.lostwells.org (Hank) - 2015-10-28 18:54 +0000
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-28 12:47 -0700
Re: the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-28 15:46 -0400
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-28 12:50 -0700
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 08:33 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-30 04:55 +1100
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-31 15:18 +1100
Re: the FORTH computer language pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 19:34 +0000
Re: the FORTH computer language Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-29 19:43 +0000
Re: the FORTH computer language pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 20:04 +0000
Re: the FORTH computer language hancock4@bbs.cpcn.com - 2015-10-29 13:28 -0700
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-30 16:43 +0000
Re: the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-29 15:37 -0400
Re: the FORTH computer language rpw3@rpw3.org (Rob Warnock) - 2015-11-03 06:56 +0000
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
Re: the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-29 15:47 -0400
Re: the FORTH computer language Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 14:14 -0600
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-30 20:50 -0400
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-30 13:54 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-28 16:05 +1100
Re: the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-28 15:52 -0400
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-29 12:29 +1100
Re: the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-29 15:51 -0400
Re: the FORTH computer language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-26 09:05 -0600
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-26 14:44 -0500
Re: the FORTH computer language hancock4@bbs.cpcn.com - 2015-10-27 10:28 -0700
Re: PDP-11, was the FORTH computer language John Levine <johnl@iecc.com> - 2015-10-26 17:19 +0000
Re: PDP-11, was the FORTH computer language Rich Alderson <news@alderson.users.panix.com> - 2015-10-26 17:02 -0400
Re: PDP-11, was the FORTH computer language pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 19:40 +0000
Re: the FORTH computer language "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-26 14:34 -0500
Re: the FORTH computer language Huge <Huge@nowhere.much.invalid> - 2015-10-26 21:22 +0000
Re: the FORTH computer language Morten Reistad <first@last.name.invalid> - 2015-10-27 07:00 +0100
Re: the FORTH computer language timcaffrey420@gmail.com - 2015-10-27 10:15 -0700
Re: the FORTH computer language scott@slp53.sl.home (Scott Lurndal) - 2015-10-27 20:09 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-27 06:42 +1100
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 15:22 -0700
Re: the FORTH computer language Quadibloc <jsavard@ecn.ab.ca> - 2015-10-26 15:23 -0700
Re: the FORTH computer language Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-27 19:55 +0000
Re: the FORTH computer language Michael Black <et472@ncf.ca> - 2015-10-27 16:09 -0400
Re: the FORTH computer language Elliott Roper <nospam@yrl.co.uk> - 2015-10-25 19:31 +0000
Re: the FORTH computer language jmfbahciv <See.above@aol.com> - 2015-10-26 12:03 +0000
Re: the FORTH computer language scott@slp53.sl.home (Scott Lurndal) - 2015-10-26 13:10 +0000
Re: the FORTH computer language "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-27 06:45 +1100
Re: the FORTH computer language Stan Barr <plan.b@bluesomatic.org> - 2015-10-24 07:03 +0000
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | pechter@S20.pechter.dyndns.org (William Pechter) |
|---|---|
| Date | 2015-10-26 16:25 +0000 |
| Message-ID | <n0lk4v$uv4$1@pechter.eternal-september.org> |
| In reply to | #153344 |
In article <bd153a4b-1988-4a90-8647-73b425f793d0@googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: >On Monday, October 26, 2015 at 8:02:23 AM UTC-6, Quadibloc wrote: >> On Monday, October 26, 2015 at 7:49:46 AM UTC-6, Quadibloc wrote: > >> > The PDP-9 was microcoded (which surprised me, given the nature of its >> > instruction set) - Gordon Bell notes that in his book "Computer >Engineering". > >> Reviewing that book, I first saw a mention that the 11/20 was hardwired, >> and the PDP-11 instruction set was simple enough not to make microcode >compulsory. >> Then it was noted that the PDP-11/60 used microcode, and even had a >> writable control store, so that customers could add their own functionality; >> and that the 11/40 made a more limited use of microcode. Later, it was noted >> that all the PDP-11 models used microcoded control units with the sole >> exception of the 11/20 (page 329) as someone noted in this thread. > >There's even a table on page 337: > >The LSI-11 used 22-bit wide vertical microinstructions; the others used >horizontal microinstructions: > >The 11/04 and 11/10 used 40-bit microinstructions; >The 11/34 and 11/60 used 48-bit microinstructions; >The 11/40 used 56-bit microinstructions; and >The 11/45 used 64-bit microinstructions. > >The PDP-11/70, however, is not mentioned in that table. The Wikipedia page on >the PDP-11 refers to the /35 as a version of the /40, and the /50, /55, and >/70 as versions of the /45, but the extent to which this is true of the > internal implementation is not clear. The 11/35 was an oem labeled 11/40 as the 11/05 and 11/10 were the same hardware. I worked on one of the beta 11/35's that I found out doing cardiac care monitoring for a DEC oem -- Bauch and Lomb. The 11/45 11/50 and 11/55 were basically different revisions of the same thing that used different memory technology... core, mos, and bipolar on the fastbus. I think the 11/55's usually were the later KB11-D cpu rather than the KB11-A. The 11/70 was basically an 11/45 with added cache, a single unibus and a separate memory bus can cache and built-in RH controllers due to the cache and memory bus. The 11/70 unibus was slow... but the 32 bit memory bus was a nice improvement in performance. IIRC The KB11-A and D were basically the same cpu with the KB11-D being the updated version with the new fixed FP11C instead of the FP11B. (I think the difference was async FPU vs. the better FP11-C which was on the 11/55's. The KB11-D was based a bit on the KB11-C which was the 11/70 (and the KB11-CM was the modified 11/74 SMP cpu IIRC). ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/1145/EK-KB11A-MM-004_Aug76.pdf ftp://ftp.dbit.com/pub/pdp11/faq/faq.pages/11model.html >The /44 was a bit-slice design, so it would have had to have been >microprogrammed, but no details are provided. > >John Savard Bill -- -- Digital had it then. Don't you wish you could buy it now! pechter-at-gmail.com http://xkcd.com/705/
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-10-26 14:36 -0500 |
| Message-ID | <n0lv7v$g5t$1@dont-email.me> |
| In reply to | #153343 |
"Quadibloc" <jsavard@ecn.ab.ca> wrote in message news:f7b69272-8c9a-4a46-a0ae-6f5e9f5a41fb@googlegroups.com... > On Monday, October 26, 2015 at 7:49:46 AM UTC-6, Quadibloc wrote: > >> The PDP-9 was microcoded (which surprised me, given the nature of its >> instruction set) - Gordon Bell notes that in his book "Computer >> Engineering". > > Reviewing that book, I first saw a mention that the 11/20 was hardwired, > and > the PDP-11 instruction set was simple enough not to make microcode > compulsory. > Then it was noted that the PDP-11/60 used microcode, and even had a > writable > control store, so that customers could add their own functionality; and > that > the 11/40 made a more limited use of microcode. Later, it was noted that > all > the PDP-11 models used microcoded control units with the sole exception of > the > 11/20 (page 329) as someone noted in this thread. > ISTM that the LSI-11 I worked on... had an extra IC socket for a floating point microcode extention. If you wanted the floating point instructions, you paid extra and got the extra chip. -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Michael Black <et472@ncf.ca> |
|---|---|
| Date | 2015-10-26 17:41 -0400 |
| Message-ID | <alpine.LNX.2.02.1510261738390.28044@darkstar.example.org> |
| In reply to | #153356 |
On Mon, 26 Oct 2015, Charles Richmond wrote: > "Quadibloc" <jsavard@ecn.ab.ca> wrote in message > news:f7b69272-8c9a-4a46-a0ae-6f5e9f5a41fb@googlegroups.com... >> On Monday, October 26, 2015 at 7:49:46 AM UTC-6, Quadibloc wrote: >> >>> The PDP-9 was microcoded (which surprised me, given the nature of its >>> instruction set) - Gordon Bell notes that in his book "Computer >>> Engineering". >> >> Reviewing that book, I first saw a mention that the 11/20 was hardwired, >> and >> the PDP-11 instruction set was simple enough not to make microcode >> compulsory. >> Then it was noted that the PDP-11/60 used microcode, and even had a >> writable >> control store, so that customers could add their own functionality; and >> that >> the 11/40 made a more limited use of microcode. Later, it was noted that >> all >> the PDP-11 models used microcoded control units with the sole exception of >> the >> 11/20 (page 329) as someone noted in this thread. >> > > ISTM that the LSI-11 I worked on... had an extra IC socket for a floating > point microcode extention. If you wanted the floating point instructions, > you paid extra and got the extra chip. > That sounds familiar. The 68000 had a similar arrangement (so I assume it came from what you remember), so if a certain code was implemented, it caused an exception or something so you could run software. I think specifically for floating point, but maybe for others. So early versions of Linux had floating point in software, while later it wasn't needed because it had been added in hardware. But there was an anticipation of the future, so when the hardware coprocessor came along, it was seemless. Michael
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-10-27 15:26 -0500 |
| Message-ID | <n0omig$qq6$1@dont-email.me> |
| In reply to | #153366 |
"Michael Black" <et472@ncf.ca> wrote in message news:alpine.LNX.2.02.1510261738390.28044@darkstar.example.org... > On Mon, 26 Oct 2015, Charles Richmond wrote: > >> "Quadibloc" <jsavard@ecn.ab.ca> wrote in message >> news:f7b69272-8c9a-4a46-a0ae-6f5e9f5a41fb@googlegroups.com... >>> On Monday, October 26, 2015 at 7:49:46 AM UTC-6, Quadibloc wrote: >>> >>>> The PDP-9 was microcoded (which surprised me, given the nature of its >>>> instruction set) - Gordon Bell notes that in his book "Computer >>>> Engineering". >>> >>> Reviewing that book, I first saw a mention that the 11/20 was hardwired, >>> and >>> the PDP-11 instruction set was simple enough not to make microcode >>> compulsory. >>> Then it was noted that the PDP-11/60 used microcode, and even had a >>> writable >>> control store, so that customers could add their own functionality; and >>> that >>> the 11/40 made a more limited use of microcode. Later, it was noted that >>> all >>> the PDP-11 models used microcoded control units with the sole exception >>> of the >>> 11/20 (page 329) as someone noted in this thread. >>> >> >> ISTM that the LSI-11 I worked on... had an extra IC socket for a floating >> point microcode extention. If you wanted the floating point >> instructions, you paid extra and got the extra chip. >> > That sounds familiar. The 68000 had a similar arrangement (so I assume it > came from what you remember), so if a certain code was implemented, it > caused an exception or something so you could run software. I think > specifically for floating point, but maybe for others. So early versions > of Linux had floating point in software, while later it wasn't needed > because it had been added in hardware. But there was an anticipation of > the future, so when the hardware coprocessor came along, it was seemless. > Michael, ISTM that you are talking about "trapping out" to a subroutine to do the floating point instructions. That's *not* what I meant. I meant that there were extra *microcode* instructions that accomplished the floating point processing. So this actually allowed the CPU to recognize and execute the floating point instructions directly. -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Michael Black <et472@ncf.ca> |
|---|---|
| Date | 2015-10-27 22:47 -0400 |
| Message-ID | <alpine.LNX.2.02.1510272244120.30329@darkstar.example.org> |
| In reply to | #153405 |
On Tue, 27 Oct 2015, Charles Richmond wrote: > "Michael Black" <et472@ncf.ca> wrote in message > news:alpine.LNX.2.02.1510261738390.28044@darkstar.example.org... >> On Mon, 26 Oct 2015, Charles Richmond wrote: >> >>> "Quadibloc" <jsavard@ecn.ab.ca> wrote in message >>> news:f7b69272-8c9a-4a46-a0ae-6f5e9f5a41fb@googlegroups.com... >>>> On Monday, October 26, 2015 at 7:49:46 AM UTC-6, Quadibloc wrote: >>>> >>>>> The PDP-9 was microcoded (which surprised me, given the nature of its >>>>> instruction set) - Gordon Bell notes that in his book "Computer >>>>> Engineering". >>>> >>>> Reviewing that book, I first saw a mention that the 11/20 was hardwired, >>>> and >>>> the PDP-11 instruction set was simple enough not to make microcode >>>> compulsory. >>>> Then it was noted that the PDP-11/60 used microcode, and even had a >>>> writable >>>> control store, so that customers could add their own functionality; and >>>> that >>>> the 11/40 made a more limited use of microcode. Later, it was noted that >>>> all >>>> the PDP-11 models used microcoded control units with the sole exception >>>> of the >>>> 11/20 (page 329) as someone noted in this thread. >>>> >>> >>> ISTM that the LSI-11 I worked on... had an extra IC socket for a floating >>> point microcode extention. If you wanted the floating point instructions, >>> you paid extra and got the extra chip. >>> >> That sounds familiar. The 68000 had a similar arrangement (so I assume it >> came from what you remember), so if a certain code was implemented, it >> caused an exception or something so you could run software. I think >> specifically for floating point, but maybe for others. So early versions >> of Linux had floating point in software, while later it wasn't needed >> because it had been added in hardware. But there was an anticipation of >> the future, so when the hardware coprocessor came along, it was seemless. >> > > Michael, ISTM that you are talking about "trapping out" to a subroutine to do > the floating point instructions. That's *not* what I meant. I meant that > there were extra *microcode* instructions that accomplished the floating > point processing. So this actually allowed the CPU to recognize and execute > the floating point instructions directly. > I see. So you paid extra for the optional ROM that extended the microcode set to do floating point. I was thinking more of the ability to extend things, rather than how it was done. Michael
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-10-27 12:22 +0000 |
| Message-ID | <PM000523155F10ED51@aca410a7.ipt.aol.com> |
| In reply to | #153342 |
Quadibloc wrote: > On Monday, October 26, 2015 at 6:02:25 AM UTC-6, jmfbahciv wrote: >> Those didn't have microcode. If they did, I sure >> don't remember the filenames. > > Microcode isn't (necessarily) stored in files. It's a way to implement the > computer's instruction set, and is still built into the hardware in most cases. > If it is loaded externally, a special mechanism is needed so that it can happen > when the computer doesn't even work yet. (Thus, as an example, one IBM 370 > model loaded the microcode from the first 8-inch floppy disk - it wasn't in a > file on one of the 3330 hard drives hooked to it.) You forget that I worked for the manufacturer. If it was a file, I had to package it on the distribution tapes so that a cold start could be done. That includes the -11s we used for the KL front end and remote stations. If it was burnt in on the manufacturing floor, then Field Service had to have some way to access it which also included part of my packaging of the diagnositc packs. I simply don't remember a filename for that function. > > The PDP-9 was microcoded (which surprised me, given the nature of its > instruction set) - Gordon Bell notes that in his book "Computer Engineering". /BAH
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-10-27 09:03 -0600 |
| Message-ID | <1boafkxsjb.fsf@pfeifferfamily.net> |
| In reply to | #153375 |
jmfbahciv <See.above@aol.com> writes: > > You forget that I worked for the manufacturer. If it was a file, I had > to package it on the distribution tapes so that a cold start could be > done. That includes the -11s we used for the KL front end and remote > stations. If it was burnt in on the manufacturing floor, then Field > Service had to have some way to access it which also included part > of my packaging of the diagnositc packs. I simply don't remember > a filename for that function. And that's the thing -- unless it had WCS, there would not have been a microcode file.
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-10-27 15:38 -0500 |
| Message-ID | <n0on8k$tm3$1@dont-email.me> |
| In reply to | #153379 |
"Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message news:1boafkxsjb.fsf@pfeifferfamily.net... > jmfbahciv <See.above@aol.com> writes: >> >> You forget that I worked for the manufacturer. If it was a file, I had >> to package it on the distribution tapes so that a cold start could be >> done. That includes the -11s we used for the KL front end and remote >> stations. If it was burnt in on the manufacturing floor, then Field >> Service had to have some way to access it which also included part >> of my packaging of the diagnositc packs. I simply don't remember >> a filename for that function. > > And that's the thing -- unless it had WCS, there would not have been a > microcode file. WCS == "writable control store" -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2015-10-27 08:43 -0700 |
| Message-ID | <f37e8053-6dec-417e-9367-2ed6419d07d2@googlegroups.com> |
| In reply to | #153375 |
On Tuesday, October 27, 2015 at 6:22:45 AM UTC-6, jmfbahciv wrote: > You forget that I worked for the manufacturer. If it was a file, I had > to package it on the distribution tapes so that a cold start could be > done. That includes the -11s we used for the KL front end and remote > stations. If it was burnt in on the manufacturing floor, then Field > Service had to have some way to access it which also included part > of my packaging of the diagnositc packs. I simply don't remember > a filename for that function. That does seem to cover the case of "if it wasn't a file". The 11/60, at least, had writeable control store, and customers were even provided with tools to prepare their own microcode. So, if you worked on manufacturing PDP-11/60 computers, you probably should have seen something. (If I understand Bell's book correctly, though, user microcode could not replace all the DEC microcode; it could modify interrupt service, and it could supply a user instruction for one special opcode only. So DEC microcode for that machine could still have been in a special place.) As for other models of the PDP-11 - well, there are a lot of ways to implement microcode. Some don't involve "burning in" microcode at all. For example, on the PDP-9, which was microcoded, the microcode was implemented by putting wires corresponding to "1" bits through holes in a ferrite rod, or something like that. Computer files wouldn't help much in that - unless they're used to generate paper tape for something similar to a Gardner-Denver wire-wrap machine. For some models of the PDP-11, the microcode was likely on ROMs, but they could well have been mask-programmed ROMs. Which means all you would have seen was a part number on the manufacturing floor - there would be a file with the microcode in it, and a copy would have been sent to the chipmaker from which Digital bought the ROMs. (Given that Digital did make its own chips at one point - the Alpha microprocessor comes to mind, this may have happened at a different Digital facility rather than at a third-party supplier.) John Savard
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-10-27 15:43 -0500 |
| Message-ID | <n0ongl$uja$1@dont-email.me> |
| In reply to | #153382 |
"Quadibloc" <jsavard@ecn.ab.ca> wrote in message news:f37e8053-6dec-417e-9367-2ed6419d07d2@googlegroups.com... > On Tuesday, October 27, 2015 at 6:22:45 AM UTC-6, jmfbahciv wrote: > >> You forget that I worked for the manufacturer. If it was a file, I had >> to package it on the distribution tapes so that a cold start could be >> done. That includes the -11s we used for the KL front end and remote >> stations. If it was burnt in on the manufacturing floor, then Field >> Service had to have some way to access it which also included part >> of my packaging of the diagnositc packs. I simply don't remember >> a filename for that function. > > That does seem to cover the case of "if it wasn't a file". > > The 11/60, at least, had writeable control store, and customers were even > provided with tools to prepare their own microcode. So, if you worked on > manufacturing PDP-11/60 computers, you probably should have seen > something. (If > I understand Bell's book correctly, though, user microcode could not > replace > all the DEC microcode; it could modify interrupt service, and it could > supply a > user instruction for one special opcode only. So DEC microcode for that > machine > could still have been in a special place.) > > As for other models of the PDP-11 - well, there are a lot of ways to > implement microcode. Some don't involve "burning in" microcode at all. > > For example, on the PDP-9, which was microcoded, the microcode was > implemented > by putting wires corresponding to "1" bits through holes in a ferrite rod, > or > something like that. Computer files wouldn't help much in that - unless > they're > used to generate paper tape for something similar to a Gardner-Denver > wire-wrap > machine. > > For some models of the PDP-11, the microcode was likely on ROMs, but they > could > well have been mask-programmed ROMs. Which means all you would have seen > was a > part number on the manufacturing floor - there would be a file with the > microcode in it, and a copy would have been sent to the chipmaker from > which > Digital bought the ROMs. (Given that Digital did make its own chips at one > point - the Alpha microprocessor comes to mind, this may have happened at > a > different Digital facility rather than at a third-party supplier.) > Gardner-Denver wire-wrap machine == contraption :-) And the programming for these machines was usually done in APT. -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | hankvc@blackhole.lostwells.org (Hank) |
|---|---|
| Date | 2015-10-28 19:05 +0000 |
| Message-ID | <n0r695$fq1$1@dont-email.me> |
| In reply to | #153409 |
In article <n0ongl$uja$1@dont-email.me>, Charles Richmond <numerist@aquaporin4.com> wrote: > >Gardner-Denver wire-wrap machine == contraption :-) > >And the programming for these machines was usually done in APT. > APT? (Automatically Programmed Tools). Not at Waltham Wire-Wrap. We had at least three programs I can remember (two run on a 360/370) and one on a Univac 1108) that took wire lists, calculated run lengths and dressing finger locations (4 on a 14-40 Gardner Denver) and assigned wrap levels (3 planes on Augat hardware). I brought APT into Raytheon to support the machine shops quite separately, and I know that the wire-wrap programs predated that by at least five years. It would have been quite an exercise to program a 14-40 wire list into APT moves. Hank
[toc] | [prev] | [next] | [standalone]
| From | "78lp" <78lp@nospam.com> |
|---|---|
| Date | 2015-10-28 16:08 +1100 |
| Message-ID | <d9b3hvFev7cU1@mid.individual.net> |
| In reply to | #153382 |
"Quadibloc" <jsavard@ecn.ab.ca> wrote in message news:f37e8053-6dec-417e-9367-2ed6419d07d2@googlegroups.com... > On Tuesday, October 27, 2015 at 6:22:45 AM UTC-6, jmfbahciv wrote: > >> You forget that I worked for the manufacturer. If it was a file, I had >> to package it on the distribution tapes so that a cold start could be >> done. That includes the -11s we used for the KL front end and remote >> stations. If it was burnt in on the manufacturing floor, then Field >> Service had to have some way to access it which also included part >> of my packaging of the diagnositc packs. I simply don't remember >> a filename for that function. > > That does seem to cover the case of "if it wasn't a file". > > The 11/60, at least, had writeable control store, and customers were even > provided with tools to prepare their own microcode. So, if you worked on > manufacturing PDP-11/60 computers, you probably should have seen > something. (If > I understand Bell's book correctly, though, user microcode could not > replace > all the DEC microcode; it could modify interrupt service, and it could > supply a > user instruction for one special opcode only. So DEC microcode for that > machine > could still have been in a special place.) > > As for other models of the PDP-11 - well, there are a lot of ways to > implement microcode. Some don't involve "burning in" microcode at all. > > For example, on the PDP-9, which was microcoded, the microcode was > implemented > by putting wires corresponding to "1" bits through holes in a ferrite rod, > or > something like that. Nope, that was done with the wiring of the flip chip discrete transistor modules. > Computer files wouldn't help much in that - unless they're > used to generate paper tape for something similar to a Gardner-Denver > wire-wrap > machine. > > For some models of the PDP-11, the microcode was likely on ROMs, but they > could > well have been mask-programmed ROMs. Which means all you would have seen > was a > part number on the manufacturing floor - there would be a file with the > microcode in it, and a copy would have been sent to the chipmaker from > which > Digital bought the ROMs. (Given that Digital did make its own chips at one > point - the Alpha microprocessor comes to mind, this may have happened at > a > different Digital facility rather than at a third-party supplier.)
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2015-10-28 05:43 -0700 |
| Message-ID | <5aece666-ec58-4cfe-a71c-a8bdc2c69bfe@googlegroups.com> |
| In reply to | #153428 |
On Tuesday, October 27, 2015 at 11:08:17 PM UTC-6, 78lp wrote: > "Quadibloc" <jsavard@ecn.ab.ca> wrote in message > news:f37e8053-6dec-417e-9367-2ed6419d07d2@googlegroups.com... > > For example, on the PDP-9, which was microcoded, the microcode was > > implemented > > by putting wires corresponding to "1" bits through holes in a ferrite rod, > > or > > something like that. > Nope, that was done with the wiring of the flip chip discrete transistor > modules. Ah, here we are; this is what I read: "A 64-word, 36-bit, 212-nanosecond read-only, transformer-coupled, rope memory was used as the microprogrammed control store." This was on page 154, in the description of the PDP-9. John Savard
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-10-27 15:37 -0500 |
| Message-ID | <n0on75$th0$1@dont-email.me> |
| In reply to | #153375 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM000523155F10ED51@aca410a7.ipt.aol.com... > Quadibloc wrote: >> On Monday, October 26, 2015 at 6:02:25 AM UTC-6, jmfbahciv wrote: >>> Those didn't have microcode. If they did, I sure >>> don't remember the filenames. >> >> Microcode isn't (necessarily) stored in files. It's a way to implement >> the >> computer's instruction set, and is still built into the hardware in most > cases. >> If it is loaded externally, a special mechanism is needed so that it can > happen >> when the computer doesn't even work yet. (Thus, as an example, one IBM >> 370 >> model loaded the microcode from the first 8-inch floppy disk - it wasn't >> in > a >> file on one of the 3330 hard drives hooked to it.) > > You forget that I worked for the manufacturer. If it was a file, I had > to package it on the distribution tapes so that a cold start could be > done. That includes the -11s we used for the KL front end and remote > stations. If it was burnt in on the manufacturing floor, then Field > Service had to have some way to access it which also included part > of my packaging of the diagnositc packs. I simply don't remember > a filename for that function. > BAH, were you in the plant where the CPUs were built??? Microcode is usually just an integral part of the CPU itself. Microcode orchestrates the steps that the CPU takes internally... to accomplish each machine language instruction. The microcode for a PDP-10 processor would *not* be distributed with the OS files. From what I have seen on the internet, the KS10 processor was implemented with microcode. -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Lawrence Statton <lawrence@senguio.mx> |
|---|---|
| Date | 2015-10-27 18:48 -0600 |
| Message-ID | <87r3kfu80l.fsf@redbull.i-did-not-set--mail-host-address--so-tickle-me> |
| In reply to | #153407 |
"Charles Richmond" <numerist@aquaporin4.com> writes:
> BAH, were you in the plant where the CPUs were built??? Microcode is
> usually just an integral part of the CPU itself.
Today it is, but that was not always the case.
> Microcode orchestrates the steps that the CPU takes internally... to
> accomplish each machine language instruction. The microcode for a
> PDP-10 processor would *not* be distributed with the OS files.
For the KL it exactly was ... I'm trying very hard to remember the name,
but it was one of the files on the filesystem for the FE, and during the
startup process, the PDP-11 shoved the microcode into the KL10 through
it's noodly appendages.
> From what I have seen on the internet, the KS10 processor was
> implemented with microcode.
That is correct -- I don't remember how the KS got its microcode during
the startup process.
I had much more experience with the WCS on the vaxen ... On the 730, the
microcode was shoved into the cpu WCS by the console processor, reading
a file called POWER.BIN off of the TU58. Some of those "reserved to
{DEC|Digital}" opcodes could wrangle and mangle the WCS during
processing to make your life More Exciting.
On the 780, it was a similar process, except that it came off the
console 8" floppy.
The 750 was the odd-man-out -- it had a PROM control store, and a
kludgiferou quasi-WCS called the "Patchable Control Store" which had
two memories ... a one-bit memory the same size as the Control Store (4
or 8K words, I can't remember now) that said "Use the word from the ROMs
or use the word from the patch space" and an equally sized overlay that
held the microcode patches. (According to a pal who managed a large
farm of 750s running BSD, that was actually an after-release *UPGRADE*
because DEC was going insane with the cost and hassle of managing
microcode patches when the microcode was stored in 128 fusible-link
PROMs).
The patch store was loaded during the boot process.
I don't remember the EXACT number, but there were something like 80
revisions of microcode for the 750.
"Oh - that trap is buggy on rev 74, you need to upgrade to rev 77, but
that requires somesuch ECO which makes some other thing less reliable
and .. hey, would youn't you rather just upgrade to a 8200?"
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-10-28 12:58 +0000 |
| Message-ID | <PM00052329E1D3F8CF@aca4145e.ipt.aol.com> |
| In reply to | #153418 |
Lawrence Statton wrote:
> "Charles Richmond" <numerist@aquaporin4.com> writes:
>> BAH, were you in the plant where the CPUs were built??? Microcode is
>> usually just an integral part of the CPU itself.
>
> Today it is, but that was not always the case.
>
>> Microcode orchestrates the steps that the CPU takes internally... to
>> accomplish each machine language instruction. The microcode for a
>> PDP-10 processor would *not* be distributed with the OS files.
>
> For the KL it exactly was ... I'm trying very hard to remember the name,
> but it was one of the files on the filesystem for the FE, and during the
> startup process, the PDP-11 shoved the microcode into the KL10 through
> it's noodly appendages.
UA.MCB for Model A KLs and UA.MCB for Model B KLs. KS10.ULD for KSs.
>
>> From what I have seen on the internet, the KS10 processor was
>> implemented with microcode.
>
> That is correct -- I don't remember how the KS got its microcode during
> the startup process.
YOu used SMFILE to build the disk file for the microcode using the Boot
magtape.
>
> I had much more experience with the WCS on the vaxen ... On the 730, the
> microcode was shoved into the cpu WCS by the console processor, reading
> a file called POWER.BIN off of the TU58. Some of those "reserved to
> {DEC|Digital}" opcodes could wrangle and mangle the WCS during
> processing to make your life More Exciting.
>
> On the 780, it was a similar process, except that it came off the
> console 8" floppy.
>
> The 750 was the odd-man-out -- it had a PROM control store, and a
> kludgiferou quasi-WCS called the "Patchable Control Store" which had
> two memories ... a one-bit memory the same size as the Control Store (4
> or 8K words, I can't remember now) that said "Use the word from the ROMs
> or use the word from the patch space" and an equally sized overlay that
> held the microcode patches. (According to a pal who managed a large
> farm of 750s running BSD, that was actually an after-release *UPGRADE*
> because DEC was going insane with the cost and hassle of managing
> microcode patches when the microcode was stored in 128 fusible-link
> PROMs).
>
> The patch store was loaded during the boot process.
>
> I don't remember the EXACT number, but there were something like 80
> revisions of microcode for the 750.
>
> "Oh - that trap is buggy on rev 74, you need to upgrade to rev 77, but
> that requires somesuch ECO which makes some other thing less reliable
> and .. hey, would youn't you rather just upgrade to a 8200?"
Good Grief! They shipped the patches? DEC was infected with Autopatch
for a long time. I had no idea it had traveled to the VAX world.
/BAH
[toc] | [prev] | [next] | [standalone]
| From | Lawrence Statton <lawrence@senguio.mx> |
|---|---|
| Date | 2015-10-28 08:15 -0600 |
| Message-ID | <878u6n5bb4.fsf@redbull.i-did-not-set--mail-host-address--so-tickle-me> |
| In reply to | #153435 |
jmfbahciv <See.above@aol.com> writes: >> The patch store was loaded during the boot process. >> >> [deletia] >> > Good Grief! They shipped the patches? DEC was infected with Autopatch > for a long time. I had no idea it had traveled to the VAX world. > > /BAH Well - I suspect that particular road to hell was paved with the very BEST of best intentions... "We are so very smart now, we may need one, maybe two patches to the microcode over the product lifespan ... we'll just ship them out as a giant box of PROM's, or do exchanges on the L0005 modules, it won't be bad." I suspect after about the twelfth microcode change, someone decided "We need a way to do this without throwing away and replacing a hundreds of dollars of PROMs.(per installed machine)" and thus was born the L0008. (Okay - actually I bet it was after the SECOND change that field service started squawking for it ... it just took another several iterations of replacing a critical board in the CPU that the bean-counters noticed the expense and allowed engineering to solve the problem, and then a whirlwind effort to build and debug the L0008 PCS replacement board)
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-10-29 13:55 +0000 |
| Message-ID | <PM0005233EBDA77ED0@aca42db5.ipt.aol.com> |
| In reply to | #153441 |
Lawrence Statton wrote: > jmfbahciv <See.above@aol.com> writes: >>> The patch store was loaded during the boot process. >>> >>> [deletia] >>> >> Good Grief! They shipped the patches? DEC was infected with Autopatch >> for a long time. I had no idea it had traveled to the VAX world. >> >> /BAH > > Well - I suspect that particular road to hell was paved with the very > BEST of best intentions... "We are so very smart now, we may need one, > maybe two patches to the microcode over the product lifespan ... we'll > just ship them out as a giant box of PROM's, or do exchanges on the > L0005 modules, it won't be bad." Not for the VAXes. The engineers' first experiences were done designing the KLs. They were people who learned from their mistakes. > > I suspect after about the twelfth microcode change, someone decided "We > need a way to do this without throwing away and replacing a hundreds of > dollars of PROMs.(per installed machine)" and thus was born the L0008. > > (Okay - actually I bet it was after the SECOND change that field service > started squawking for it ... it just took another several iterations of > replacing a critical board in the CPU that the bean-counters noticed the > expense and allowed engineering to solve the problem, and then a > whirlwind effort to build and debug the L0008 PCS replacement board) > There still has to be a file. DEC's practice was to package such things with each release so that archives could be retrieved in cases of firefights and disasters. hmmm....unless the files were "owned" by Diagnostics. That group's culture never learned how to package their software with the same strictures we did with all the other software DEC developed. Diagnostics did learn at the end but it was too late to set up the infrastructure. The -10's were set up in a very quick and dirty method without any verifications. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Lawrence Statton <lawrence@senguio.mx> |
|---|---|
| Date | 2015-10-29 08:37 -0600 |
| Message-ID | <87611p4u7h.fsf@redbull.i-did-not-set--mail-host-address--so-tickle-me> |
| In reply to | #153510 |
jmfbahciv <See.above@aol.com> writes: > There still has to be a file. DEC's practice was to package such things > with each release so that archives could be retrieved in cases of > firefights and disasters. I've no doubt there were not less than N files ... An archival copy of whatever was in the PROMs for each version of L0005, and when the '5 was abandoned, the base-line code for each of the ROM sets in the L0008, and then a copy of each of the variants of the PCS store. Not sure what point you are trying to make. > > /BAH
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-10-30 13:54 +0000 |
| Message-ID | <PM000523528730DCFE@aca424b4.ipt.aol.com> |
| In reply to | #153521 |
Lawrence Statton wrote: > jmfbahciv <See.above@aol.com> writes: >> There still has to be a file. DEC's practice was to package such things >> with each release so that archives could be retrieved in cases of >> firefights and disasters. > > I've no doubt there were not less than N files ... An archival copy of > whatever was in the PROMs for each version of L0005, and when the '5 was > abandoned, the base-line code for each of the ROM sets in the L0008, and > then a copy of each of the variants of the PCS store. > > Not sure what point you are trying to make. I'm trying to remember the file names. /BAH
[toc] | [prev] | [next] | [standalone]
Page 3 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