Re: DEC KS10 implementation - was CDC 6600 emulation

[Rob Doyle]

On 6/20/2016 9:07 PM, ben wrote:

On 6/20/2016 9:43 PM, Eric Smith wrote:

On Mon, Jun 20, 2016 at 9:34 PM, ben 
wrote:

My other pet-peave is that every thing is point and click wizard
 for any useful modules. Need a rom module or adder module, point
 and click no portable code.


I predominantly use Xilinx, and I don't use much point-and-click
at all. I do all my HDL editing in emacs, including instantiating
any of the Xilinx-provided IP blocks. My main interaction with the
 Xilinx software (whether ISE or Vivado) is to click the "generate
 bitstream" button.  It's even possible to do that from the command
 line or a Makefile, but I haven't bothered.


Do you use Static or Dynamic ram with the FPGA's? Ben.


Another example -

The KS10 FPGA uses 36-bit wide 166 MHz synchronous static RAM (SSRAM)
for main memory. Main memory is as fast as the "Fast ACs". I didn't
bother to implement cache (why bother?) and the Cache Diagnostic still
whines that things that should not be cached are being cached...

Most good tools can infer about everything from a well written HDL
description. This includes single port and multi-port memory and
includes RAM and ROM. The less tool-specific things that you use, the
more portable your design is.

The only IP block that I regularly use is a phased-locked-loop block.

The DEC KS10 used a lot of asynchronous parts (memory, FIFOs/SILOs,
one-shots, delay lines, RC delays, etc) that don't map very well to
modern components - especially FPGAs. I've elected to redesign circuitry
as necessary to use the FPGA resources. Others have elected to retain
the original design as close as possible and accept the consequences.

The KS10 FPGA is at:
http://www.techtravels.org/?page_id=656
https://github.com/KS10FPGA/KS10FPGA

The ALU out of the KS10 FPGA describes a fairly complex circuit
containing memory, registers, multiplexers, shifters, adders, including
an am2901 4-bit slice processor-based ALU all written using generic
Verilog. Also the HDL description has trace tags back to the card,
schematic sheet, and reference designators of the original design - if
you'd like to compare the two.

The KS10 FPGA ALU design can be viewed at:
https://github.com/KS10FPGA/KS10FPGA/blob/master/fpga/ks10/cpu/alu.v

Regarding simulation - a full Verilog simulation of the DEC RP06 disk
diagnostic (DSRPA) requires about two and a half weeks to complete on my
fastest computer. That's maybe not suprising because that simulates the
entire CPU running the diagnostic program, memory, the unibus adapters,
the RH11 disk controller, the console terminal, and eight RP06 disk
drives. When run on the target FPGA, the DSRPA diagnostic completes in
slightly less than 9 minutes.

Rob.
doyle (at) cox (dot) net

Re: How do they make Verilog code for unknown ICs?

[Peter Corlett]

On Mon, Jun 20, 2016 at 01:35:46PM -0600, Swift Griggs wrote:
[...]
> Why are folks referring to "Verilogging" and "doing a verilog" on older
> chips. Is there some way you can stuff an IC into a socket or alligator clip
> a bunch of tiny leads onto it and then "map" it somehow into Verilog?

Only for trivial chips that do not maintain (much) state, such as ROMs and 74xx
chips which (almost) always generate the same output for a given set of inputs,
so it is possible to exhaustively search all of the possible states.

Useful chips use RTL[0] designs which contain registers (aka latches,
flip-flops, etc) that hold internal state. The outputs now vary not only on the
inputs but also on the registers, and there are far to many states to be able
to search them all. An example of a chip that makes heavy use of registers is a
CPU itself, and it is not plausible to try and automatically figure out the
instruction set of a novel CPU based just on its bus interface.

In practice, one would hoover up as much documentation as possible and come up
with a prototype in HDL that implements the inferred spec, then compare it
against how the real chip works. This will almost certainly not work first
time, so one then gets to fix the bugs and iterate until the copy is good
enough for the given application. This is the sort of thing that effortlessly
soaks up man-years of effort.


[0] https://en.wikipedia.org/wiki/Register-transfer_level

Programming for the Alto's Mesa

[Liam Proven]

>From the discussions around Y Combinator's Alto restoration...

(Some may not know that the founder of Y Combinator is Paul Graham,
using some of the money Yahoo! paid him for Viaweb, which became Yahoo
Stores. PG is a Lisp champion and evangelist.)

The Alto restoration is being discussed on Hacker News, Y Combinator's
very successful forums:

https://news.ycombinator.com/item?id=11929396

This comment struck me:

«
Animats 2 days ago

I just looked in some boxes I haven't opened in decades. I have "Mesa
Language Manual, Version 5.0, April 1979". If the people with the Alto
need this, let me know.

If the world had used Mesa instead of C, computing would have been far
less buggy. Mesa was a hard-compiled language, but it had concurrency,
monitors, co-routines ("ports", similar to Go channels), strong type
safety, and a sane way to pass arrays around. In the 1970s.

(I should donate this stuff to the Computer Museum. I just found the
original DEC Small Computer Manual, many 1960s UNIVAC mainframe
manuals, and a reel of UNIVAC I steel magnetic tape.)
»

I knew that the original Smalltalk boxes weren't Smalltalk all the way
down to the metal, and that there was an OS and language, Mesa,
underneath... but I didn't know it was used for anything much *else*
or that some considered it important.

Anyone here know or remember Mesa? I'd like to hear more about it.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: How do they make Verilog code for unknown ICs?

[Alan Hightower]

 

Verilator is another good tool for doing functional/behavioral
simulation of Verilog with a C/C++ test frame-work. 

-Alan 

On 2016-06-20 17:05, Seth Morabito wrote: 

> * On Mon, Jun 20, 2016 at 04:19:56PM -0400, Paul Koning 
>  wrote: 
> 
>> I haven't looked for open source Verilog simulators.
> 
> I've used Icarus Verilog ('iverilog') in the past. It's pretty bare
> bones, but you can feed the output into gnuplot and make reasonable
> diagrams from it.
> 
>> paul
> 
> -Seth
 

Re: Programming for the Alto's Mesa

[Toby Thain]

On 2016-06-21 9:46 AM, Liam Proven wrote:

From the discussions around Y Combinator's Alto restoration...


(Some may not know that the founder of Y Combinator is Paul Graham,
using some of the money Yahoo! paid him for Viaweb, which became Yahoo
Stores. PG is a Lisp champion and evangelist.)

The Alto restoration is being discussed on Hacker News, Y Combinator's
very successful forums:

https://news.ycombinator.com/item?id=11929396

This comment struck me:

«
Animats 2 days ago

I just looked in some boxes I haven't opened in decades. I have "Mesa
Language Manual, Version 5.0, April 1979". If the people with the Alto
need this, let me know.

If the world had used Mesa instead of C, computing would have been far
less buggy.


That's for certain. It's one of several systems programming languages 
with safety: the Solo operating system in Concurrent Pascal is another 
example.


> Mesa was a hard-compiled language, but it had concurrency,

monitors, co-routines ("ports", similar to Go channels), strong type
safety, and a sane way to pass arrays around. In the 1970s.

(I should donate this stuff to the Computer Museum. I just found the


Scan & publish the documents first, if that can be done without 
guillotining -- because they won't.


[Actually if anyone knows who accepts paper documents, please comment; 
currently I know Jason Scott / Internet Archive does? I plan to scan a 
lot of what I have then divest the paper.]



original DEC Small Computer Manual, many 1960s UNIVAC mainframe
manuals, and a reel of UNIVAC I steel magnetic tape.)
»

I knew that the original Smalltalk boxes weren't Smalltalk all the way
down to the metal, and that there was an OS and language, Mesa,
underneath... but I didn't know it was used for anything much *else*
or that some considered it important.

Anyone here know or remember Mesa? I'd like to hear more about it.



The operating system "Pilot" was written in Mesa. A relevant paper is 
reprinted in Brinch Hansen's "Classic Operating Systems": "Pilot: An 
Operating System for a Personal Computer" (1980).


Another paper cited in the book is "Early experience with Mesa," 
Geschke, C.M., J.H. Morris Jr., and E.H. Satterthwaite, Comm. ACM 20, 8 
(Aug 1977). (later, Geschke was a cofounder of Adobe Systems).


--Toby

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Paul Koning]

> On Jun 20, 2016, at 11:53 PM, Chuck Guzis  wrote:
> 
> Are you going for the 6600 CPU with PPU or just the CPU itself?

The whole thing.  The intent is to be able to run code, and you need PPUs for 
that.  Besides, part of the motivation was to understand esoteric details of 
how PPUs work.  The PPUs are actually straightforward; I have those running.  
The CPU is trickier, and of course much larger.

paul

Sun4 370 PSU Maintenance/Schematics

[asw...@t-online.de]

Hello all,
 
I do have an Symbolics UX1200 plugged into a Sun4 370 host.
 
Before powering the host, just to be secure, I'd like to check the psu - or 
if the psu will be broken, I'd like to try to fix it.
Yesterday I'd a look into the psu - very complicated layout!
 
Is there any known documentation, servicing and maintenance documentation 
or schematics for psus used in Sun server/workstation available, of course 
esp. for psus used in Sun4 370 systems?
 
-- Andreas


Re: Programming for the Alto's Mesa

[Josh Dersch]

On 6/21/16 6:46 AM, Liam Proven wrote:

>From the discussions around Y Combinator's Alto restoration...

(Some may not know that the founder of Y Combinator is Paul Graham,
using some of the money Yahoo! paid him for Viaweb, which became Yahoo
Stores. PG is a Lisp champion and evangelist.)

The Alto restoration is being discussed on Hacker News, Y Combinator's
very successful forums:

https://news.ycombinator.com/item?id=11929396

This comment struck me:

«
Animats 2 days ago

I just looked in some boxes I haven't opened in decades. I have "Mesa
Language Manual, Version 5.0, April 1979". If the people with the Alto
need this, let me know.

If the world had used Mesa instead of C, computing would have been far
less buggy. Mesa was a hard-compiled language, but it had concurrency,
monitors, co-routines ("ports", similar to Go channels), strong type
safety, and a sane way to pass arrays around. In the 1970s.

(I should donate this stuff to the Computer Museum. I just found the
original DEC Small Computer Manual, many 1960s UNIVAC mainframe
manuals, and a reel of UNIVAC I steel magnetic tape.)
»

I knew that the original Smalltalk boxes weren't Smalltalk all the way
down to the metal, and that there was an OS and language, Mesa,
underneath... but I didn't know it was used for anything much *else*
or that some considered it important.
The "original" Smalltalk box(*), the Alto, wasn't Mesa-based.  (Mesa was 
originally developed on the Alto, sort of in parallel with Smalltalk).  
Smalltalk was originally written in Alto assembly language (which was 
basically Data General Nova assembly) and was later implemented in Alto 
microcode and became self-hosting/bootstrapping (it was written in 
itself).  Smalltalk was never written in Mesa, though on the later 
D-machines it ran inside a Mesa-based environment.


(*) The original Smalltalk prototype was written in BASIC on a Data 
General Nova.  It wasn't very fast.


Anyone here know or remember Mesa? I'd like to hear more about it.

Mesa became the basis for much of the software on Xerox's later 
D-machines (the Star and its successors).  It was compiled into a 
byte-coded stack-based machine code (the bytecode interpreter was 
implemented in microcode on the Alto and later machines) and apparently 
the code density was pretty remarkable (from what I've read).  The 
Viewpoint GUI and applications were written in it.  It was a 
strongly-typed high-level language with exceptions.  I don't (yet) have 
any direct experience in using the language, but it's something I want 
to get around to one of these days.


- Josh

Re: Programming for the Alto's Mesa

[Ian S. King]

On Tue, Jun 21, 2016 at 8:09 AM, Josh Dersch  wrote:

>
>> Mesa became the basis for much of the software on Xerox's later
> D-machines (the Star and its successors).  It was compiled into a
> byte-coded stack-based machine code (the bytecode interpreter was
> implemented in microcode on the Alto and later machines) and apparently the
> code density was pretty remarkable (from what I've read).  The Viewpoint
> GUI and applications were written in it.  It was a strongly-typed
> high-level language with exceptions.  I don't (yet) have any direct
> experience in using the language, but it's something I want to get around
> to one of these days.
>
> - Josh
>

ISTR that BravoX was written in Mesa.  -- Ian

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: DEC KS10 implementation - was CDC 6600 emulation

[Lee Courtney]

"When run on the target FPGA, the DSRPA diagnostic completes in
slightly less than 9 minutes."

Any idea what the run-time would be a on a real KS10?

Lee C.

On Tue, Jun 21, 2016 at 1:18 AM, Rob Doyle  wrote:

> On 6/20/2016 9:07 PM, ben wrote:
>
>> On 6/20/2016 9:43 PM, Eric Smith wrote:
>>
>>> On Mon, Jun 20, 2016 at 9:34 PM, ben 
>>> wrote:
>>>
 My other pet-peave is that every thing is point and click wizard
  for any useful modules. Need a rom module or adder module, point
  and click no portable code.

>>>
>>> I predominantly use Xilinx, and I don't use much point-and-click
>>> at all. I do all my HDL editing in emacs, including instantiating
>>> any of the Xilinx-provided IP blocks. My main interaction with the
>>>  Xilinx software (whether ISE or Vivado) is to click the "generate
>>>  bitstream" button.  It's even possible to do that from the command
>>>  line or a Makefile, but I haven't bothered.
>>>
>>> Do you use Static or Dynamic ram with the FPGA's? Ben.
>>
>
> Another example -
>
> The KS10 FPGA uses 36-bit wide 166 MHz synchronous static RAM (SSRAM)
> for main memory. Main memory is as fast as the "Fast ACs". I didn't
> bother to implement cache (why bother?) and the Cache Diagnostic still
> whines that things that should not be cached are being cached...
>
> Most good tools can infer about everything from a well written HDL
> description. This includes single port and multi-port memory and
> includes RAM and ROM. The less tool-specific things that you use, the
> more portable your design is.
>
> The only IP block that I regularly use is a phased-locked-loop block.
>
> The DEC KS10 used a lot of asynchronous parts (memory, FIFOs/SILOs,
> one-shots, delay lines, RC delays, etc) that don't map very well to
> modern components - especially FPGAs. I've elected to redesign circuitry
> as necessary to use the FPGA resources. Others have elected to retain
> the original design as close as possible and accept the consequences.
>
> The KS10 FPGA is at:
> http://www.techtravels.org/?page_id=656
> https://github.com/KS10FPGA/KS10FPGA
>
> The ALU out of the KS10 FPGA describes a fairly complex circuit
> containing memory, registers, multiplexers, shifters, adders, including
> an am2901 4-bit slice processor-based ALU all written using generic
> Verilog. Also the HDL description has trace tags back to the card,
> schematic sheet, and reference designators of the original design - if
> you'd like to compare the two.
>
> The KS10 FPGA ALU design can be viewed at:
> https://github.com/KS10FPGA/KS10FPGA/blob/master/fpga/ks10/cpu/alu.v
>
> Regarding simulation - a full Verilog simulation of the DEC RP06 disk
> diagnostic (DSRPA) requires about two and a half weeks to complete on my
> fastest computer. That's maybe not suprising because that simulates the
> entire CPU running the diagnostic program, memory, the unibus adapters,
> the RH11 disk controller, the console terminal, and eight RP06 disk
> drives. When run on the target FPGA, the DSRPA diagnostic completes in
> slightly less than 9 minutes.
>
> Rob.
> doyle (at) cox (dot) net
>



-- 
Lee Courtney
+1-650-704-3934 cell

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Chuck Guzis]

On 06/21/2016 07:25 AM, Paul Koning wrote:
> 
>> On Jun 20, 2016, at 11:53 PM, Chuck Guzis 
>> wrote:
>> 
>> Are you going for the 6600 CPU with PPU or just the CPU itself?
> 
> The whole thing.  The intent is to be able to run code, and you need
> PPUs for that.  Besides, part of the motivation was to understand
> esoteric details of how PPUs work.  The PPUs are actually
> straightforward; I have those running.  The CPU is trickier, and of
> course much larger.

I take it that your PPs use the "one ALU, ten memories" model of the
6600 and not the independent PPUs of the 7600 and 180?

Will your 6600 have an option for ECS?

--Chuck

Re: Programming for the Alto's Mesa

[Josh Dersch]

On 6/21/16 8:14 AM, Ian S. King wrote:

On Tue, Jun 21, 2016 at 8:09 AM, Josh Dersch  wrote:


Mesa became the basis for much of the software on Xerox's later

D-machines (the Star and its successors).  It was compiled into a
byte-coded stack-based machine code (the bytecode interpreter was
implemented in microcode on the Alto and later machines) and apparently the
code density was pretty remarkable (from what I've read).  The Viewpoint
GUI and applications were written in it.  It was a strongly-typed
high-level language with exceptions.  I don't (yet) have any direct
experience in using the language, but it's something I want to get around
to one of these days.

- Josh


ISTR that BravoX was written in Mesa.  -- Ian

Yes it was, as was MazeWar and the Laurel mail client (and many other 
things).


- Josh

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Paul Koning]

> On Jun 21, 2016, at 11:24 AM, Chuck Guzis  wrote:
> 
> On 06/21/2016 07:25 AM, Paul Koning wrote:
>> 
>>> On Jun 20, 2016, at 11:53 PM, Chuck Guzis 
>>> wrote:
>>> 
>>> Are you going for the 6600 CPU with PPU or just the CPU itself?
>> 
>> The whole thing.  The intent is to be able to run code, and you need
>> PPUs for that.  Besides, part of the motivation was to understand
>> esoteric details of how PPUs work.  The PPUs are actually
>> straightforward; I have those running.  The CPU is trickier, and of
>> course much larger.
> 
> I take it that your PPs use the "one ALU, ten memories" model of the
> 6600 and not the independent PPUs of the 7600 and 180?

Correct, because my model is a gate level transcription of the original design. 
 I'm NOT building this model from the system functional specification, but 
rather from the actual module schematics and wire lists.

> Will your 6600 have an option for ECS?

That's the intent.  This is tricky because I have not seen wire lists for the 
ECS coupler.  I should be able to do without the ECS controller (modeling ECS 
functionally at that interface point).  But the ECS coupler contains details 
that the CPU hooks into, and also some semi-unrelated details like 
central/monitor exchange jump processing.

There are block diagrams, and those will have to serve if all else fails, but 
that means reverse engineering the module level detail (or, more precisely, 
constructing a functionally equivalent set of module level details).  I keep 
hoping that some day the missing details will be found.  Similarly, there are 
some other details that are missing; the PPU wire lists predate the 
central/monitor exchange jump feature so that too would have to be 
reconstructed from less detailed information.

paul

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[dwight]

One has to realize that all complex chips are done in Verilog or VHDL. Many old 
designs in processors can be re-implemented from timing and bus diagrams.

This is no longer possible with todays processors like Intel or AMD processors. 
The complexity of possible sequential events are more than is practical to try 
to analyze from the pins.

One can implement an instruction set but you'll never get close to the bus 
activity of current processors.

 I would say that the most important part of either language is the ability to 
describe the time of simultaneous events. This is unlike most programs written 
in C or such. Of course, one can write a simulation language in C.

Dwight



From: cctalk  on behalf of Chuck Guzis 

Sent: Tuesday, June 21, 2016 8:24:44 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for 
unknown ICs?

On 06/21/2016 07:25 AM, Paul Koning wrote:
>
>> On Jun 20, 2016, at 11:53 PM, Chuck Guzis 
>> wrote:
>>
>> Are you going for the 6600 CPU with PPU or just the CPU itself?
>
> The whole thing.  The intent is to be able to run code, and you need
> PPUs for that.  Besides, part of the motivation was to understand
> esoteric details of how PPUs work.  The PPUs are actually
> straightforward; I have those running.  The CPU is trickier, and of
> course much larger.

I take it that your PPs use the "one ALU, ten memories" model of the
6600 and not the independent PPUs of the 7600 and 180?

Will your 6600 have an option for ECS?

--Chuck

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Chuck Guzis]

On 06/21/2016 08:35 AM, Paul Koning wrote:

> There are block diagrams, and those will have to serve if all else
> fails, but that means reverse engineering the module level detail
> (or, more precisely, constructing a functionally equivalent set of
> module level details).  I keep hoping that some day the missing
> details will be found.  Similarly, there are some other details that
> are missing; the PPU wire lists predate the central/monitor exchange
> jump feature so that too would have to be reconstructed from less
> detailed information.

Wasn't CEJ/MEJ a field-installable ECO?   Maybe there's paper on that
somewhere.

ECS to me would be the real bugger, since it isn't just a box of core
sitting off to the side.  On the Cybers, didn't it also include the ILR?
 That was too many years ago.  I do remember that it made the business
of RCH/DCH much simpler in PPRES--no need to go through MTR.

Well, when you're done with the 6600, you can work up a STAR 100 :)  I'm
not aware of even a software emulator being available for that one.

--Chuck

Re: Programming for the Alto's Mesa

[Cameron Kaiser]

> (*) The original Smalltalk prototype was written in BASIC on a Data 
> General Nova.  It wasn't very fast.

Wow. Does this code exist anywhere?

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Just another Sojourner of the Dispersion (1 Peter 1:1) -

Re: Programming for the Alto's Mesa

[Noel Chiappa]

> From: Josh Dersch

>> ISTR that BravoX was written in Mesa.  -- Ian

> Yes it was, as was MazeWar

?? There was a MazeWar on the Alto, early on, and I'm not sure that version
was in Mesa. Maybe someone re-implemned it in Mesa for some of the later
machines? (Of course, all the Xerox ones were inspired by the much earlier
Imlac one.)

Noel

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Chuck Guzis]

On 06/21/2016 08:47 AM, dwight wrote:

> I would say that the most important part of either language is the
> ability to describe the time of simultaneous events. This is unlike
> most programs written in C or such. Of course, one can write a
> simulation language in C.

I tend to think of Verilog/VHDL/SystemC as being first cousins to the
much older event simulation languages, Simscript Simula and GPSS. I
believe that in the early days of LSI, one or more of them were actually
used in the design process.

If you've used any of the aforementioned simulation languages, then
transitioning to VHDL/Verilog is much easier.

--Chuck

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Paul Koning]

> On Jun 21, 2016, at 12:07 PM, Chuck Guzis  wrote:
> 
> On 06/21/2016 08:35 AM, Paul Koning wrote:
> 
>> There are block diagrams, and those will have to serve if all else
>> fails, but that means reverse engineering the module level detail
>> (or, more precisely, constructing a functionally equivalent set of
>> module level details).  I keep hoping that some day the missing
>> details will be found.  Similarly, there are some other details that
>> are missing; the PPU wire lists predate the central/monitor exchange
>> jump feature so that too would have to be reconstructed from less
>> detailed information.
> 
> Wasn't CEJ/MEJ a field-installable ECO?   Maybe there's paper on that
> somewhere.

Early on it may have been an ECO; later it became "standard option 10104 C/D".  
An ECO document would certainly serve, but I haven't seen that either.

> ECS to me would be the real bugger, since it isn't just a box of core
> sitting off to the side.  On the Cybers, didn't it also include the ILR?
> That was too many years ago.  I do remember that it made the business
> of RCH/DCH much simpler in PPRES--no need to go through MTR.

I don't recognize "ILR".  The control for central exchange (XJ instruction) is 
is largely in the ECS coupler partly because some of the exchange package state 
(RAX/FLX/MA) lives there, as does the monitor mode flag.  Also partly because 
XJ and RE/WE are 01 opcodes that use the same address calculation.  I think 
once you get past the coupler into ECS itself and the ECS controller, there 
aren't any execution-related bits.  Not unless you count the Flag Register, 
which is a set of mutexes operated on by ECS read/write operations.

paul

Re: Sun4 370 PSU Maintenance/Schematics

[aswood]

It's a Zyrtec 925Watts psu.

Any Zyrtec schematics, service or repair manuals anywhere?

I do like the Astec service manuals, e.g. for the SMBX 36xx series psus. 

-- Andreas

> Am 21.06.2016 um 16:36 schrieb "asw...@t-online.de" :
> 
> Hello all,
> 
> I do have an Symbolics UX1200 plugged into a Sun4 370 host.
> 
> Before powering the host, just to be secure, I'd like to check the psu - or 
> if the psu will be broken, I'd like to try to fix it.
> Yesterday I'd a look into the psu - very complicated layout!
> 
> Is there any known documentation, servicing and maintenance documentation 
> or schematics for psus used in Sun server/workstation available, of course 
> esp. for psus used in Sun4 370 systems?
> 
> -- Andreas
> 

Re: Programming for the Alto's Mesa

[Al Kossow]

On 6/21/16 9:12 AM, Noel Chiappa wrote:
> I'm not sure that version
> was in Mesa.

I am, since I have the code.

Re: Programming for the Alto's Mesa

[Al Kossow]

On 6/21/16 8:25 AM, Josh Dersch wrote:

> Yes it was, as was MazeWar and the Laurel mail client (and many other things).
>

Alto software evolved throughout the 70's. It started out bare-bones as they 
bootstrapped
themselves up. Mesa was developed in parallel, as was Smalltalk. Mesa is an 
Algol-like
strongly typed language with the notion of modules and with internal and 
external interface.
This is all documented on bitsavers and in the source tree at CHM. Mesa is a 
bit too big to
run comfortably even on the max memory Alto with two disk drives. By the time 
the language
was in wider use they had D-machines to run it on. SDD stayed with Mesa for 
their product
development, PARC CSL evolved Mesa into Cedar, with things like integrated 
garbage collection.

The build system used in XDE and the D-machines is extremely powerful. Builds 
were completely
distributed across many servers with the distributed build system managing the 
packaging and
dependencies.

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Chuck Guzis]

On 06/21/2016 09:24 AM, Paul Koning wrote:

> I don't recognize "ILR".  The control for central exchange (XJ
> instruction) is is largely in the ECS coupler partly because some of
> the exchange package state (RAX/FLX/MA) lives there, as does the
> monitor mode flag.  Also partly because XJ and RE/WE are 01 opcodes
> that use the same address calculation.  I think once you get past the
> coupler into ECS itself and the ECS controller, there aren't any
> execution-related bits.  Not unless you count the Flag Register,
> which is a set of mutexes operated on by ECS read/write operations.

ILR = "Interlock Register"

It was mutex setup, but on a per-system, rather than as a global ECS
thing like the flags register--and accessible only to PPs.  Any word in
it could be read by any PP.

Either 64 or 128 bits located on PP channel 15 (octal).  The only
mention that I could find of it in the bitsavers collection was for the
Cyber 74, but it was on lower Cybers as well.

http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/cyber_70/60347400N_Cyber70_Model74_Comp_Sys_Vol1_Jun77.pdf

PDF page 48.

I don't know if it was a retrofit for older 6000 systems, but it would
seem to make sense if it was.  It simplified the RCH/DCH PP channel
reservation calls enormously.

--Chuck

Re: DEC KS10 implementation - was CDC 6600 emulation

[Rob Doyle]

On 6/21/2016 8:15 AM, Lee Courtney wrote:

"When run on the target FPGA, the DSRPA diagnostic completes in
slightly less than 9 minutes."

Any idea what the run-time would be a on a real KS10?

Lee C.


I don't know. I suspect it wouldn't be very different. The KS10 FPGA
CPU is about 4x faster than the DEC KS10.

http://www.techtravels.org/KS10FPGA/DSKFA.pdf

Having said that, the RP06 Disk can be conditionally compiled in one
of two modes: "fast and loose" and "slow but accurate".

The "slow but accurate" mode is required to pass many of the DSRPA
diagnostics. The FPGA simulates head motion (seek times), disk
rotation (search times), and data transfer rates.

I'm guessing that the physical delays in the disk drive dominate the
timing of the DSRPA diagnostic - and those delays should be pretty accurate.

The RP06 uses a Secure Digital Card (SDHC) as media. The "fast and
loose" mode just uses the SD Card with very little external delays.
That seems to be good enough for everything but everything except
the diagnostics and is consistent with the SIMH implementation.

https://github.com/KS10FPGA/KS10FPGA/issues/8

Rob.

Re: HP Series-80 computers - PRM-85 board case? ... maybe!

[Jochen Kunz]

Am 20.06.16 um 15:20 schrieb martin.heppe...@dlr.de:
> So: if someone owning a 3D printer and a PRM-85 board is interested
> in helping me to refine the design by making a test print I could
> supply the STL files for upper and lower shells.
I highly recommend to contact your local hackerspace:
https://stratum0.org/wiki/Hauptseite
They offer 3D printers for use:
https://stratum0.org/wiki/3D-Drucker
There you will find several people experienced with 3D printing and
willing to help you.
-- 

tschüß,
   Jochen

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[ben]

On 6/21/2016 9:47 AM, dwight wrote:

One has to realize that all complex chips are done in Verilog or
VHDL. Many old designs in processors can be re-implemented from
timing and bus diagrams.


Where do you get this info? Most of the little stuff I have seen
it is still graphic layout and Intel (or IBM ...) is not going to
tell you their design style.


This is no longer possible with todays processors like Intel or AMD
processors. The complexity of possible sequential events are more
than is practical to try to analyze from the pins.

One can implement an instruction set but you'll never get close to
the bus activity of current processors.


Who knows what secrets the cache holds?


I would say that the most important part of either language is the
ability to describe the time of simultaneous events. This is unlike
most programs written in C or such. Of course, one can write a
simulation language in C.


And a useless feature in my view. Real hardware has real delays
and simulation is prone errors translating to the real hardware.


Ben.


Dwight



PS: With the speed of modern transistors routing capacitance
and large die size; I think Vacuum tube/Drum memory might be better 
model for modern computing.

old friend is slimming down the warehouse

[Electronics Plus]

An old friend of mine in GA is slimming down his warehouse. I know a long
time ago people sent me some pics and lists of things wanted, but that was a
long time ago. If you are looking for old servers, big blue IBM things, DEC
stuff, etc., please take a few minutes to send the following info to
oldthingswanted...@gmail.com

 

The name of the item

A short description

A link to a pic, or attach a pic

What you want to pay for it

The expected condition (tested, old and dirty is fine, etc.)

His health is not the best, but he wants this stuff to go to people who will
appreciate it, rather than by the pound.

He will do his best to answer everyone.

 

Inventory ranges from old typewriters to mainframes, and everything in
between.

 

Cindy Croxton

Electronics Plus

Re: old friend is slimming down the warehouse

[Guy Sotomayor Jr]

Is there any sort of list of what he has or are we just to send out our “wish 
list”
and see if he has it?

TTFN - Guy

> On Jun 21, 2016, at 12:27 PM, Electronics Plus  wrote:
> 
> An old friend of mine in GA is slimming down his warehouse. I know a long
> time ago people sent me some pics and lists of things wanted, but that was a
> long time ago. If you are looking for old servers, big blue IBM things, DEC
> stuff, etc., please take a few minutes to send the following info to
> oldthingswanted...@gmail.com
> 
> 
> 
> The name of the item
> 
> A short description
> 
> A link to a pic, or attach a pic
> 
> What you want to pay for it
> 
> The expected condition (tested, old and dirty is fine, etc.)
> 
> His health is not the best, but he wants this stuff to go to people who will
> appreciate it, rather than by the pound.
> 
> He will do his best to answer everyone.
> 
> 
> 
> Inventory ranges from old typewriters to mainframes, and everything in
> between.
> 
> 
> 
> Cindy Croxton
> 
> Electronics Plus
> 

RE: old friend is slimming down the warehouse

[Electronics Plus]

He does not have a list. Warehouse is about 50k sq feet, and was started in the 
1970s.
Like I said, his health is not good, but he wants to find a good home for these.
If sending lists does not work, I can ask him to pick some things out and send 
me description and pics so I can post here?
He does not have pricing in mind, so please be fair when you ask or offer.

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Guy Sotomayor 
Jr
Sent: Tuesday, June 21, 2016 2:35 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: old friend is slimming down the warehouse

Is there any sort of list of what he has or are we just to send out our “wish 
list”
and see if he has it?

TTFN - Guy

> On Jun 21, 2016, at 12:27 PM, Electronics Plus  wrote:
> 
> An old friend of mine in GA is slimming down his warehouse. I know a 
> long time ago people sent me some pics and lists of things wanted, but 
> that was a long time ago. If you are looking for old servers, big blue 
> IBM things, DEC stuff, etc., please take a few minutes to send the 
> following info to oldthingswanted...@gmail.com
> 
> 
> 
> The name of the item
> 
> A short description
> 
> A link to a pic, or attach a pic
> 
> What you want to pay for it
> 
> The expected condition (tested, old and dirty is fine, etc.)
> 
> His health is not the best, but he wants this stuff to go to people 
> who will appreciate it, rather than by the pound.
> 
> He will do his best to answer everyone.
> 
> 
> 
> Inventory ranges from old typewriters to mainframes, and everything in 
> between.
> 
> 
> 
> Cindy Croxton
> 
> Electronics Plus
> 

Re: old friend is slimming down the warehouse

[Todd Killingsworth]

Cindy,  I'm in Atlanta... where in GA is he?  Maybe I could go meet him
somewhere and take pictures?

Todd Killingsworth

On Tue, Jun 21, 2016 at 3:38 PM, Electronics Plus 
wrote:

> He does not have a list. Warehouse is about 50k sq feet, and was started
> in the 1970s.
> Like I said, his health is not good, but he wants to find a good home for
> these.
> If sending lists does not work, I can ask him to pick some things out and
> send me description and pics so I can post here?
> He does not have pricing in mind, so please be fair when you ask or offer.
>
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Guy
> Sotomayor Jr
> Sent: Tuesday, June 21, 2016 2:35 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: old friend is slimming down the warehouse
>
> Is there any sort of list of what he has or are we just to send out our
> “wish list”
> and see if he has it?
>
> TTFN - Guy
>
> > On Jun 21, 2016, at 12:27 PM, Electronics Plus 
> wrote:
> >
> > An old friend of mine in GA is slimming down his warehouse. I know a
> > long time ago people sent me some pics and lists of things wanted, but
> > that was a long time ago. If you are looking for old servers, big blue
> > IBM things, DEC stuff, etc., please take a few minutes to send the
> > following info to oldthingswanted...@gmail.com
> >
> >
> >
> > The name of the item
> >
> > A short description
> >
> > A link to a pic, or attach a pic
> >
> > What you want to pay for it
> >
> > The expected condition (tested, old and dirty is fine, etc.)
> >
> > His health is not the best, but he wants this stuff to go to people
> > who will appreciate it, rather than by the pound.
> >
> > He will do his best to answer everyone.
> >
> >
> >
> > Inventory ranges from old typewriters to mainframes, and everything in
> > between.
> >
> >
> >
> > Cindy Croxton
> >
> > Electronics Plus
> >
>
>
>
>

Re: Monitor refresh rate query

[Noel Chiappa]

> From: Chuck Guzis

> It's not the refresh rate that will kill things, but the horizontal
> frequency. The high voltage in most CRT monitors (and TVs) is developed
> from the scanning signal via a high-voltage "flyboack" transformer
> ...
> Ultimately, if taken too far, the voltage in the FBT secondary exceeds
> the ratings of the winding insulation; an arc develops between windings
> and the FBT self-destructs

So, with Chuck's explanation (above) in hand, eventually my brain turned on,
and I was able to work out what the deal is, and whether my monitor is safe;
it also explains the somewhat contradictory CRT monitor manual:

  HP M50 manual says "Setting the screen resolution/refresh rate combination
  higher than 1024x768 at 60 Hz can damage the display." Even though the same
  document lists the vertical frequency range as "50-100 Hz"!

They mention both the resolution and "refresh rate" since those two together
control the horizontal flyback frequency, which Chuck pointed out as the key.
(Well, the line count - 768 - is involved there, not the line length in
pixels - although the latter will influence the maximum video bandwith or
"dot rate" that needs to be supported - 65 MHz for this particular monitor.)

The horizontal retrace frequency is simply the vertical retrace frequency,
times the number of scan lines per vertical retrace plus a small slop factor
for the actual retrace duration.

So my monitor was running 1024x768 - but interlaced, so only 364 lines per
screen scan (alternating odd and even lines in successive scans). I was
seeing a refresh frequency of 44 Hz - but for full scan of all lines; the
actual vertical retrace is being produced at 87 Hz. So the horizontal retrace
frequency is about 87 * 364 = ~32 KHz - well within what the monitor can
handle (30-49 Khz for the horizontal retrace, per the spec). So the monitor
is safe!

Probably by the time this monitor came out, the interlaced XGA format had
fallen into disuse, and so they didn't need to clarify that
"resolution/refresh rate combination higher than 1024x768 at 60 Hz can damage
the display" refers to 'progressive' displays, not interlaced.

And of course, as previously pointed out, the interlace explains why no LCD
displays will work. So I'll have to carefully hoard my remaining video
monitors! ;-)


Thanks to everyone who helped me work this out...

Noel

RE: HP Series-80 computers - PRM-85 board case? ... maybe!

[John Ball]

>Anyone with a 3d printer want to make one for us?
>
>J

Not only do I also own a PRM-85 but I do have part-time access to a 3D
printer. If I can get the prototyped models (and the model itself fits
within the limits of the printer bed)I can verify that they fit together in
an HP 80 series machine (85 in my case)and that the board itself fits inside
the enclosure however due to membership restrictions at our local makerspace
I cannot use the printer to fulfill any orders, plus they will eat up a lot
of filament.

-John

Re: old friend is slimming down the warehouse

[Guy Sotomayor Jr]

Yea, I’m just concerned that without some more specific parameters it’s going 
to be
really hard to come up with lists that don’t inundate him.  My other big fear 
is that
we’ll “self censor” and miss something because we figured no one has it.

TTFN - Guy

> On Jun 21, 2016, at 12:38 PM, Electronics Plus  wrote:
> 
> He does not have a list. Warehouse is about 50k sq feet, and was started in 
> the 1970s.
> Like I said, his health is not good, but he wants to find a good home for 
> these.
> If sending lists does not work, I can ask him to pick some things out and 
> send me description and pics so I can post here?
> He does not have pricing in mind, so please be fair when you ask or offer.
> 
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Guy 
> Sotomayor Jr
> Sent: Tuesday, June 21, 2016 2:35 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: old friend is slimming down the warehouse
> 
> Is there any sort of list of what he has or are we just to send out our “wish 
> list”
> and see if he has it?
> 
> TTFN - Guy
> 
>> On Jun 21, 2016, at 12:27 PM, Electronics Plus  wrote:
>> 
>> An old friend of mine in GA is slimming down his warehouse. I know a 
>> long time ago people sent me some pics and lists of things wanted, but 
>> that was a long time ago. If you are looking for old servers, big blue 
>> IBM things, DEC stuff, etc., please take a few minutes to send the 
>> following info to oldthingswanted...@gmail.com
>> 
>> 
>> 
>> The name of the item
>> 
>> A short description
>> 
>> A link to a pic, or attach a pic
>> 
>> What you want to pay for it
>> 
>> The expected condition (tested, old and dirty is fine, etc.)
>> 
>> His health is not the best, but he wants this stuff to go to people 
>> who will appreciate it, rather than by the pound.
>> 
>> He will do his best to answer everyone.
>> 
>> 
>> 
>> Inventory ranges from old typewriters to mainframes, and everything in 
>> between.
>> 
>> 
>> 
>> Cindy Croxton
>> 
>> Electronics Plus
>> 
> 
> 
> 

Re: old friend is slimming down the warehouse

[William Donzelli]

> Cindy,  I'm in Atlanta... where in GA is he?  Maybe I could go meet him
> somewhere and take pictures?

Yes, please. Gold star to you if you go.

--
Will

RE: old friend is slimming down the warehouse

[Electronics Plus]

I have sent Todd his contact info. He is willing to let one person come in and 
take pics and post to the group. He does NOT want to move one or 2 items of the 
most value; he wants to move out pallets of stuff. He is not closing shop; he 
just wants to move out some really old equip that has been there for years.

He did tell me one of the goodies he has is a Commodore 64 new in the box with 
the monitor.

Cindy

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of William 
Donzelli
Sent: Tuesday, June 21, 2016 2:50 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: old friend is slimming down the warehouse

> Cindy,  I'm in Atlanta... where in GA is he?  Maybe I could go meet 
> him somewhere and take pictures?

Yes, please. Gold star to you if you go.

--
Will

Re: old friend is slimming down the warehouse

[William Donzelli]

> I have sent Todd his contact info. He is willing to let one person come in 
> and take pics and post to the group. He does NOT want to move one or 2 items 
> of the most value; he wants to move out pallets of stuff. He is not closing 
> shop; he just wants to move out some really old equip that has been there for 
> years.

Be sure to tell your friend that the mainframe collectors can
certainly make cubic feet of equipment leave the warehouse quickly!

--
Will

Re: old friend is slimming down the warehouse

[Todd Killingsworth]

Cindy - Thanks!  I'll get in touch w/him and set up a meeting.

Will - Whoa, easy boy!  :)   I'll get pics and link them up.

Todd Killingsworth


On Tue, Jun 21, 2016 at 4:05 PM, William Donzelli 
wrote:

> > I have sent Todd his contact info. He is willing to let one person come
> in and take pics and post to the group. He does NOT want to move one or 2
> items of the most value; he wants to move out pallets of stuff. He is not
> closing shop; he just wants to move out some really old equip that has been
> there for years.
>
> Be sure to tell your friend that the mainframe collectors can
> certainly make cubic feet of equipment leave the warehouse quickly!
>
> --
> Will
>

Re: old friend is slimming down the warehouse

[Guy Sotomayor Jr]

> On Jun 21, 2016, at 1:05 PM, William Donzelli  wrote:
> 
>> I have sent Todd his contact info. He is willing to let one person come in 
>> and take pics and post to the group. He does NOT want to move one or 2 items 
>> of the most value; he wants to move out pallets of stuff. He is not closing 
>> shop; he just wants to move out some really old equip that has been there 
>> for years.
> 
> Be sure to tell your friend that the mainframe collectors can
> certainly make cubic feet of equipment leave the warehouse quickly!

Cubic yards?  ;-)

Also, if someone is going to take pictures, especially with the mainframe stuff
(since in many cases the cabinets/racks are non-descript) it is important to get
model number information.

TTFN - Guy

Re: old friend is slimming down the warehouse

[Todd Killingsworth]

<>​


Thanks Guy - I'll keep that in mind.  If this is a warehouse dive, things
may be stacked on top of one another.. I should be able to get model
numbers of machines, but cards, specific part # may be difficult.

Any other recommendations from the list at large on information to get?

Todd Killingsworth

On Tue, Jun 21, 2016 at 4:12 PM, Guy Sotomayor Jr  wrote:

>
> > On Jun 21, 2016, at 1:05 PM, William Donzelli 
> wrote:
> >
> >> I have sent Todd his contact info. He is willing to let one person come
> in and take pics and post to the group. He does NOT want to move one or 2
> items of the most value; he wants to move out pallets of stuff. He is not
> closing shop; he just wants to move out some really old equip that has been
> there for years.
> >
> > Be sure to tell your friend that the mainframe collectors can
> > certainly make cubic feet of equipment leave the warehouse quickly!
>
> Cubic yards?  ;-)
>
> Also, if someone is going to take pictures, especially with the mainframe
> stuff
> (since in many cases the cabinets/racks are non-descript) it is important
> to get
> model number information.
>
> TTFN - Guy
>
>

Re: old friend is slimming down the warehouse

[Swift Griggs]

On Tue, 21 Jun 2016, Todd Killingsworth wrote:
> Any other recommendations from the list at large on information to get?

If it says "SGI" or "Silicon Graphics" speak up someone is probably 
going to be interested. 

-Swift

Re: Programming for the Alto's Mesa

[Paul McJones]

> I just looked in some boxes I haven't opened in decades. I have "Mesa
> Language Manual, Version 5.0, April 1979". If the people with the Alto
> need this, let me know.

It’s been scanned: 
http://www.bitsavers.org/pdf/xerox/mesa/5.0_1979/documentation/CSL_79-3_Mesa_Language_Manual_Version_5.0_Apr79.pdf

> ... Mesa was a hard-compiled language, but it had concurrency,
> monitors, co-routines ("ports", similar to Go channels), strong type
> safety, and a sane way to pass arrays around. ...

The designers of the concurrency mechanisms (Butler Lampson and Dave Redell) 
wrote an excellent paper, which can be downloaded from Lampson’s web site:

http://research-srv.microsoft.com/en-us/um/people/blampson/23-ProcessesInMesa/Abstract.html

> Anyone here know or remember Mesa? I'd like to hear more about it.

Thanks to the foresight of Al Kossow and others, the Computer History Museum 
has a repository of Alto source code online, including the Mesa system and some 
applications such as the Laurel electronic mail client and the Grapevine 
distributed mail transport and name service. (The repository also includes a 
lot of BCPL and a small amount of Smalltalk.) The repository is here:

http://xeroxalto.computerhistory.org

Probably better to start here:

http://www.computerhistory.org/atchm/xerox-alto-source-code/
http://xeroxalto.computerhistory.org/xerox_alto_file_system_archive.html


Paul McJones

Re: Programming for the Alto's Mesa

[Ian S. King]

Even if you never touch an Alto (and I hope that you someday can do so!),
it's interesting to look at BCPL, an ancestor of C.  I learned to read it
fairly well when I was maintaining LCM's first Alto.  -- Ian

On Tue, Jun 21, 2016 at 12:31 PM, Paul McJones  wrote:

> > I just looked in some boxes I haven't opened in decades. I have "Mesa
> > Language Manual, Version 5.0, April 1979". If the people with the Alto
> > need this, let me know.
>
> It’s been scanned:
> http://www.bitsavers.org/pdf/xerox/mesa/5.0_1979/documentation/CSL_79-3_Mesa_Language_Manual_Version_5.0_Apr79.pdf
>
> > ... Mesa was a hard-compiled language, but it had concurrency,
> > monitors, co-routines ("ports", similar to Go channels), strong type
> > safety, and a sane way to pass arrays around. ...
>
> The designers of the concurrency mechanisms (Butler Lampson and Dave
> Redell) wrote an excellent paper, which can be downloaded from Lampson’s
> web site:
>
>
> http://research-srv.microsoft.com/en-us/um/people/blampson/23-ProcessesInMesa/Abstract.html
>
> > Anyone here know or remember Mesa? I'd like to hear more about it.
>
> Thanks to the foresight of Al Kossow and others, the Computer History
> Museum has a repository of Alto source code online, including the Mesa
> system and some applications such as the Laurel electronic mail client and
> the Grapevine distributed mail transport and name service. (The repository
> also includes a lot of BCPL and a small amount of Smalltalk.) The
> repository is here:
>
> http://xeroxalto.computerhistory.org
>
> Probably better to start here:
>
> http://www.computerhistory.org/atchm/xerox-alto-source-code/
> http://xeroxalto.computerhistory.org/xerox_alto_file_system_archive.html
>
>
> Paul McJones
>
>


-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

CDC 6600 - Why so awesome?

[Swift Griggs]

To my sorrow, I'd never heard of the CDC 6600 and I barely knew who 
Control Data was (whippersnapper, I know). I see a lot of traffic about 
them on the list and I went out to discover "why so cool?" Wikipedia and 
other spots talk about the features, but I'm trying to understand from 
folks who put hands to the metal, why they liked them so much.

I'm a total igmo concerning this bit of kit. Is this about right?

- It has dual "calligraphic" displays. Geeze! Very freakin' cool

- It was RISC nearly before folks could even articulate the concept

- It had some wicked cool "demos", to cop a C64 term. (ADC, PAC, EYE)

- It wasn't DEC and it wasn't IBM and it was faster than both when it hit 
  the street? 

- It has a cool OS? Dunno. Not much info on "SCOPE"

- Made in the USA baby! Back when we actually made things. 

- It used odd sized (by todays standards) register, instruction, and bus 
  sizes. 60 bit machine with 15/30 bit instructions. But, didn't it cause 
  a bunch of alignment issues for you ?

I dug into the CPU instructions for about 20 minutes and it was actually 
pretty straightforward. The so-called "COMPASS" ASM code was oh-so-cool. I 
can't believe they had so many of the features now considered "modern" or 
"clever" (at least by me) in the 1960s! This code:

https://en.wikipedia.org/wiki/COMPASS/Sample_Code

... Is super-readable, in fact, probably a bit more than several 
much-newer dialects on different platforms. There was one instruction 
"PROTECT" I found pretty interesting, too. Was that similar to noodling 
with the control registers CR0, CR2, CR3, and CR4 on x86 to mark memory 
protection from segmentation violations? I remember that being the 
protection mechanism on my 386 SX/16 (and I remember it being a PITA), 
however the COMPASS "way" looks much easier/cooler and must have some 
hardware assistance to do that so easily.

-Swift

Re: CDC 6600 - Why so awesome?

[Charles Anthony]

On Tue, Jun 21, 2016 at 2:06 PM, Swift Griggs  wrote:
>

>
> - It was RISC nearly before folks could even articulate the concept
>
>
> - It used odd sized (by todays standards) register, instruction, and bus
>   sizes. 60 bit machine with 15/30 bit instructions. But, didn't it cause
>   a bunch of alignment issues for you ?
>
> I dug into the CPU instructions for about 20 minutes and it was actually
> pretty straightforward. The so-called "COMPASS" ASM code was oh-so-cool. I
> can't believe they had so many of the features now considered "modern" or
> "clever" (at least by me) in the 1960s! This code:

The odd thing about the instruction set is that it did not have
load/store instructions; load/store was a side-effect -- net register
An (for n in 0-5), and the data at the memory address the register was
set to was loaded into the corresponding Xn register, for n 6 or 7,
the value in the Xn register was stored at the address.

So the extra credit exercise is to figure out how to write a
subroutine that prints out the value of all of the registers; ie. how
can you save *all* of the register values to memory?

-- Charles

Re: CDC 6600 - Why so awesome?

[Noel Chiappa]

> From: Swift Griggs

> I see a lot of traffic about them on the list and I went out to
> discover "why so cool?" 

One word - 'crunch'. The 6600 especially, but also its successors (7600, etc)
were _the_ number-crunching monsters of their day. For everyone who had a
scientific/engineering application that needed lots of cycles - especially
floating-point - that was _the_ machine to have.

IBM tried to outdo them, but spent a fortune, and didn't really get there -
the 360/9x was essentially a failure - only 15 /91's and 2 /95's were ever
built. (And IBM was later sued for predatory sales practices for announcing
them before they knew they could make them.) IBM just couldn't match Seymour
Cray.

Speaking of whom, the 6600 was the source of the famous Watson memory (and
Cray's sarcastic response) - Google it!

Noel

Found cleaning out stuff from before gray hairs and needing glasses

[Pete Lancashire]

http://petelancashire.com/gallery/main.php?g2_itemId=7139

Re: CDC 6600 - Why so awesome?

[Noel Chiappa]

> the 6600 was the source of the famous Watson memory

Oops, typo; 'memo'.

Noel

RE: CDC 6600 - Why so awesome?

[Rich Alderson]

From: Swift Griggs
Sent: Tuesday, June 21, 2016 2:06 PM

> - It used odd sized (by todays standards) register, instruction, and bus 
>   sizes. 60 bit machine with 15/30 bit instructions. But, didn't it cause 
>   a bunch of alignment issues for you ?

???  Alignment issues?  Care to define this?  Are you thinking of bytes?

The word is the addressable unit of storage.  Compilers (well, the FORTRAN
compiler, to start) and the assembler inserted 15-bit no-ops as necessary
to pad the 60-bit words of a CP program.  PP programs fit five 12-bit
instructions per word.

Character codes are 6- or mixed 6/12-bit, packed into the 60-bit word.

Where would you see alignment issues?

Rich


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

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/21/2016 02:27 PM, Charles Anthony wrote:

> So the extra credit exercise is to figure out how to write a 
> subroutine that prints out the value of all of the registers; ie.
> how can you save *all* of the register values to memory?

That one was old even in the 60s.   You use the RJ (return jump)
instruction and one of the B-register conditionals and basically add a
B-register to itself to effect a left-shift.

Restoring the registers was more interesting, IMOHO.

FWIW, MACE/KRONOS also had a XJ system call to effect the save a bit
more directly--you just grab the registers from the exchange package and
stash them away.  But you needed CEJ for that to work, though I suspect
a special MTR function could have done as well in SCOPE.

--Chuck

Re: CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/21/2016 02:06 PM, Swift Griggs wrote:

> - It had some wicked cool "demos", to cop a C64 term. (ADC, PAC, EYE)

Those were mostly toys to amuse the CEs, like the baseball game BAT.

Chess 3.0 was implemented on Northwestern's machine and probably was the
first computer chess program of note.This was before kids thought
that computer games were *cool*.  I never developed a taste for computer
gaming.

Much of the architectural concept was shared with IBM 7030 STRETCH
(another system worth researching).  Hand-timing instruction sequences
on the 6600 was an art with its own rewards.

> - It wasn't DEC and it wasn't IBM and it was faster than both when it hit 
>   the street? 

With a 10 MHz clock.

> - It has a cool OS? Dunno. Not much info on "SCOPE"

It had several *cool* OSes, but really only two major ones for general
consumption (Special Systems Dvision had several more).  SCOPE (later
NOS/BE), pretty much initially a PP-resident OS based on the old
Chippewa Operating System--and NOS (was KRONOS, originally MACE),
started as a "bootleg" project by Greg Mansfield and (Dr.) Dave
Callender at Arden Hills.  (MACE stood for "(Greg) Mansfield's Answer to
Customer Engineering".  MACE took the then-mostly PP-resident SCOPE and
transfered various non-I/O system management functions to the CPU.
Purdue also contributed quite a bit of code.   Most batch programs
written for SCOPE would run fine on MACE with few, if any,
modifications.  In retrospect, CDC keeping two operating systems (SCOPE
was part of CPD in Sunnyvale, while KRONOS stayed home in Arden Hillls)
was probably a strategic blunder, since much duplicate effort was
wasted.  Eventually, the two were merged into NOS (for Network Operating
System).

> - It used odd sized (by todays standards) register, instruction, and bus 
>   sizes. 60 bit machine with 15/30 bit instructions. But, didn't it cause 
>   a bunch of alignment issues for you ?

There aren't any alignment issues, since the CPU was only
word-addressable.   This was when a character was 6 bits (think IBM
709x, UNIVAC 1100, etc.)  So a word with 10 characters was logical.
Given that PP words 12 bits (5 to a CM word) and there were 10 PPUs,
each executing at a speed 1/10th the CPU, it had a very pleasant sort of
symmetry.

> I dug into the CPU instructions for about 20 minutes and it was actually 
> pretty straightforward. The so-called "COMPASS" ASM code was oh-so-cool. I 
> can't believe they had so many of the features now considered "modern" or 
> "clever" (at least by me) in the 1960s! This code:

COMPASS was indeed advanced for its time, but then so was OS/360
assembly language.  Given that assembly was the lingua franca of system
programming, assemblers had to be good.  Most of the readability was due
to attention to detail by the programmer, not any particular language
feature.

> ... Is super-readable, in fact, probably a bit more than several 
> much-newer dialects on different platforms. There was one instruction 
> "PROTECT" I found pretty interesting, too. 

Where did you find that?  I've never heard of such an instruction.

--Chuck

where to find DEC ECO's for KB11-A?

[Fritz Mueller]

Are DEC ECO's available online anywhere?  I have not seem them in the 
usual places e.g. bitsavers...  I am particularly interested in ECO's 
related to the KB11-A (11/45).


thanks,
--FritzM.

Still ISO: Infotek MX-30 Memory boards for Infotek FP-30 (HP 9830 upgrade)

[Josh Dersch]

Hey all --

Several years ago (well, three years ago, anyway) I stumbled upon a
beat-up, incomplete HP 9830 desktop computer/calculator that had been
upgraded with an Infotek FP-30 CPU upgrade.

Unfortunately, it's missing the special memory boards (the MX-30) the
system requires.  I asked around back then and had no luck, I figured I'd
try again.  If anyone has any parts for this rare beast, drop me a line.

Alternately, if someone else has a need for the parts I do have, let me
know and maybe we can work something out.  It would be nice to get a
working system (even if it's not mine) out of this stuff.

Thanks!
Josh

Re: CDC 6600 - Why so awesome?

[Paul Koning]

> On Jun 21, 2016, at 5:39 PM, Noel Chiappa  wrote:
> 
>> From: Swift Griggs
> 
>> I see a lot of traffic about them on the list and I went out to
>> discover "why so cool?" 
> 
> One word - 'crunch'. The 6600 especially, but also its successors (7600, etc)
> were _the_ number-crunching monsters of their day. 

Yes.  The 6600 was an amazing engineering accomplishment.  It had extremely 
fast memory for its day (under a microsecond access time, in 1964).  It could 
run several million instructions per second.  Floating point add in half a 
microsecond, multiply in one microsecond.

Lesser known things, like context switching ("exchange jump") in about 4 
microseconds (!).  And divide was done two bits per clock tick rather than the 
usual one bit per tick; essentially it was doing long division base 4 rather 
than base 2 as is common.

Also a disk drive (6603) that was WAY faster than its peers because it recorded 
data in 12 bit words parallel rather than using a serial bit stream.  I believe 
something similar was also done in the Cray 1, but CDC had it a decade earlier.

paul

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

[Michael Thompson]

The RICM just picked up a PDP-11/40 chassis that was modified to accept a
PDP-11/23 board set. It also contains a custom board to interface the
PDP-11/23 to the original PDP-11/40 front panel. It is quite an
accomplishment to get the Q-Bus board set working in the Unibus chassis.

-- 
Michael Thompson

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

[Paul Anderson]

I'm guessing the Qniverter.

On Tue, Jun 21, 2016 at 9:37 PM, Josh Dersch  wrote:

> On 6/21/16 6:05 PM, Michael Thompson wrote:
>
>> The RICM just picked up a PDP-11/40 chassis that was modified to accept a
>> PDP-11/23 board set. It also contains a custom board to interface the
>> PDP-11/23 to the original PDP-11/40 front panel. It is quite an
>> accomplishment to get the Q-Bus board set working in the Unibus chassis.
>>
>> Very interesting -- is this a homebrew affair, or does it use something
> like an Able QNIVERTER to do the job?
>
> - Josh
>

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

[Mike Ross]

On Wed, Jun 22, 2016 at 1:05 PM, Michael Thompson
 wrote:
> The RICM just picked up a PDP-11/40 chassis that was modified to accept a
> PDP-11/23 board set. It also contains a custom board to interface the
> PDP-11/23 to the original PDP-11/40 front panel. It is quite an
> accomplishment to get the Q-Bus board set working in the Unibus chassis.
>
> --
> Michael Thompson

Oh now that's fun. And useful. A blinkenlights Qbus machine! If it's
not impractical the mods should be documented so that others may go
reproduce this setup. How fancy is the custom board?!

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

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

[Josh Dersch]

On 6/21/16 6:05 PM, Michael Thompson wrote:

The RICM just picked up a PDP-11/40 chassis that was modified to accept a
PDP-11/23 board set. It also contains a custom board to interface the
PDP-11/23 to the original PDP-11/40 front panel. It is quite an
accomplishment to get the Q-Bus board set working in the Unibus chassis.

Very interesting -- is this a homebrew affair, or does it use something 
like an Able QNIVERTER to do the job?


- Josh

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

[Glen Slick]

On Tue, Jun 21, 2016 at 6:05 PM, Michael Thompson
 wrote:
> The RICM just picked up a PDP-11/40 chassis that was modified to accept a
> PDP-11/23 board set. It also contains a custom board to interface the
> PDP-11/23 to the original PDP-11/40 front panel. It is quite an
> accomplishment to get the Q-Bus board set working in the Unibus chassis.
>

What boards exactly? Are you sure it's not an M7133 11/24 board instead?

RE: HP Series-80 computers - PRM-85 board case? ... maybe!

[CuriousMarc]

Add me to the list of interested people for sure.
Marc

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jay West
Sent: Monday, June 20, 2016 10:41 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: HP Series-80 computers - PRM-85 board case? ... maybe!

I'll chime in as a 3rd person wanting a case for my PRM-85, and I know for sure 
two other listmembers (who are not the two who mentioned it just now) who will 
definitely want one.

So probably 5 takers.

Anyone with a 3d printer want to make one for us?

J

RE: Y Combinator is restoring one of Alan Kay's Xerox Alto machines

[CuriousMarc]

The restoration is physically happening at my place. As noted below we have a 
small and quite knowledgeable group of people contributing, including actual 
hardware when we are missing a part (thanks Al !). A few of us are chronicling 
this on our favorite media from our favorite angle.
I like to make short videos trying to convey the inside story of the 
restoration, on my YouTube channel:
https://www.youtube.com/curiousmarc
It's interspersed with all the other restorations, but two videos so far:
https://youtu.be/YupOC_6bfMI
https://youtu.be/xPyqQXFC2yw
Ed Thelen likes to collect every bit of raw information floating around, 
including some of the team emails and throw them into equally raw site, as he 
does for the IBM 1401 restoration effort at CHM:
http://ed-thelen.org/RestoreAlto/index.html
Carl Claunch methodically recounts everything he does every day (and he does a 
lot), so when he works on the Alto, you'll know every detail:
http://rescue1130.blogspot.com/
Ken Shirriff makes deeply researched, superlative detailed posts on his blog. 
These are reference pieces, I admire them a lot:
http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html
And it gets discussed on the Y-combinator (the owners of the machine) and 
hopefully here too. 
Seeing the interest, I will make an effort to post new links when they become 
available, unless of course Master Al beats me to it.

Marc

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Al Kossow
Sent: Monday, June 20, 2016 8:54 AM
To: cctalk@classiccmp.org
Subject: Re: Y Combinator is restoring one of Alan Kay's Xerox Alto machines

http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html
https://news.ycombinator.com/item?id=11929396
http://ed-thelen.org/RestoreAlto/index.html

On 6/20/16 8:51 AM, Al Kossow wrote:
> I post just went up on Saturday. It's nice that both CHM and LCM folks 
> are helping with this.
> 
> 
> On 6/20/16 8:41 AM, Liam Proven wrote:
>> http://www.righto.com/2016/06/y-combinators-xerox-alto-restoring.html
>>
>> Found via:
>>
>> http://www.osnews.com/story/29261/Xerox_Alto_restoring_the_legendary_
>> 1970s_GUI_computer
>>
>> There are 2 videos up so far, with disassemblies that may interest CCmpers.
>>
>> Some people from the list are involved, including Al Kossow, but I 
>> haven't seen the link posted.
>>
> 

Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[dwight]

Well Ben

I'll tell you a secret. I work for one of those two companies.

Processors are designed from such code, simulated and then

synthesized to silicon gates. I don't think that is too much of a

secret.

How the architecture is done is very much a secret. I can tell you that it is 
more complicated than one person can completely understand. It is a team effort 
with many people working from a general description of what each part does and 
how it should interact. Some work only on arrays while others work on floating 
point alu's and so on.

Each processor generation shares only a little with previous designs. To try to 
describe to someone outside how one of todays processor worked inside would 
require a book for each generation. Some parts are the same while other are 
vastly different.

It is interesting that I just read an article about the Chinese creating a 
faster supper computer. I suspect that many might think they did it with RISK 
design while most US made machines were stuck in CISC machines.

I don't have the real inside scoop but I can tell you what I think. Processors 
made today are general purpose. Floating point is a side function and not where 
the most emphasis is placed. I suspect that the Chinese designed the processors 
they used specifically to do floating point and were not the reuse of general 
purpose processors. The RISK/CISC is really not even relevant in todays 
processors since the main limiting factor is memory access bandwidth and 
effective use of caches. The instruction set used is only to deal with older 
software.

Dwight



From: cctalk  on behalf of ben 

Sent: Tuesday, June 21, 2016 11:53:20 AM
To: cctalk@classiccmp.org
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for 
unknown ICs?

On 6/21/2016 9:47 AM, dwight wrote:
> One has to realize that all complex chips are done in Verilog or
> VHDL. Many old designs in processors can be re-implemented from
> timing and bus diagrams.

Where do you get this info? Most of the little stuff I have seen
it is still graphic layout and Intel (or IBM ...) is not going to
tell you their design style.

> This is no longer possible with todays processors like Intel or AMD
> processors. The complexity of possible sequential events are more
> than is practical to try to analyze from the pins.
>
> One can implement an instruction set but you'll never get close to
> the bus activity of current processors.

Who knows what secrets the cache holds?

> I would say that the most important part of either language is the
> ability to describe the time of simultaneous events. This is unlike
> most programs written in C or such. Of course, one can write a
> simulation language in C.

And a useless feature in my view. Real hardware has real delays
and simulation is prone errors translating to the real hardware.


Ben.

> Dwight
>

PS: With the speed of modern transistors routing capacitance
and large die size; I think Vacuum tube/Drum memory might be better
model for modern computing.