Re: CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/22/2016 06:18 PM, Paul Koning wrote:
>> 
>> On Wed, 22 Jun 2016, Chuck Guzis wrote: ...
>>> Its illegitimate relative, KRONOS, made extensive use of ECS for
>>> support of the PLATO system.
> 
> Not quite.  KRONOS treated ECS (rather clumsily) as a kind of disk.
> PLATO just bypassed all that and managed ECS directly, as memory the
> way it was originally designed to be used.  After startup, PLATO
> would own all the ECS and do transfers directly, without any OS
> involvement.  It would also use ECS for inter-job communication, and
> for communication with PPU programs.  For example, PLATO disk I/O
> uses both request queues and data buffers in ECS, which the PPU
> program accesses.  Ditto for terminal I/O.

That's where SCOPE differed. A program could request a specific amount
of ECS, just like CM field lenght.  At least that was the situation in
say SCOPE 3.1.6.  ECS wasn't terribly useful in the early days.

Of course, under Zodiac (and TOOS), we kept whole program chains in ECS
shared among up to 4 systems.  A chain could run in any machine and have
any of its modules accessed from any other machine or ECS directly.  We
were very ECS hungry at a time when CDC wondered if anyone would be
willing to buy the stuff.  We may have had the first 4MW ECS setup sold
to a customer.

None of our PPUs accessed ECS directly, however.  Our database system
didn't use files either--completely random access across, IIRC, up to
144 844s online.  Neither SCOPE or KRONOS was up to that job.

--Chuck

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

[Glen Slick]

On Wed, Jun 22, 2016 at 5:28 PM, Michael Thompson
 wrote:
>
> I looked at the backplane pictures that I took after the rescue. I assumed
> that the hex-wide 8-slot backplane in the front of the card cage was the
> original 11/40 processor backplane. On the back it says "LSI 11 BACKPLANE",
> so the operation is not so mysterious. I had never seen a hex-wide Q-bus
> backplane before this.
>
> There are some pictures of the system and the Q-Bus to 11/40 front panel
> interface here: http://www.ricomputermuseum.org/Home/equipment/dec-pdp-1140
>

Maybe a DDV11-B? See pages 205-210 of the PDP-11 Microcomputer
Interfaces Handbook 1983-84:

http://www.bitsavers.org/pdf/dec/qbus/EB-23144-18_QbusIntrfs_1983.pdf

The screws on the connector blocks in groups of 1 on the first and
last rows and 3 in the center rows looks similar to those shown in
Figure 2 DDV11-B Module Installation and Slot Assignments on page 207.

CYBER-171

[Bryan C. Everly]

Wondering if anyone out there has such a machine running.  It was
literally the first computer system I used (at Indiana State
University back in the 70's).  I had some real fun doing FORTRAN and
Pascal programming on that thing.

Thanks,
Bryan

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

[Ethan Dicks]

On Wed, Jun 22, 2016 at 8:28 PM, Michael Thompson
 wrote:
> I looked at the backplane pictures that I took after the rescue. I assumed
> that the hex-wide 8-slot backplane in the front of the card cage was the
> original 11/40 processor backplane. On the back it says "LSI 11 BACKPLANE",
> so the operation is not so mysterious. I had never seen a hex-wide Q-bus
> backplane before this.

I have one... it came to me in an 11/34 with a lone IVB11 mounted in
it (Qbus IEEE-488) from a Physics Lab, and might have been marked on
the paper label DDV11CK.  It was all DEC, no Abel Qniverter, but I
can't recall what DEC module was on the Unibus to drive the Qbus (the
Qbus input paddle card was one of the ordinary ones used in a BA11N or
similar).

I never got the history, but presumably, some time in the late 1970s,
Ohio State ordered a PDP-11/34 with IEEE-488 and for whatever reason
(no IB11 available?  IB11 EOLed?), it came with an IBV11 and a bus
converter.  I'd like to dig that one out someday and try a Qbus SCSI
card on a Unibus machine.  It'll probably work if I can get a
bootstrap on the box.

> There are some pictures of the system and the Q-Bus to 11/40 front panel
> interface here: http://www.ricomputermuseum.org/Home/equipment/dec-pdp-1140

Neat!

I've dug into the 11/70 front panel schematics, so I'm pretty sure
it's "easy" to get the Qbus to drive the LEDs, at least the address
and data LEDs, but I'm wondering about the switches and how many of
them work.

-ethan

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

[Michael Thompson]

On Tue, Jun 21, 2016 at 9:05 PM, Michael Thompson <
michael.99.thomp...@gmail.com> 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.
>

I looked at the backplane pictures that I took after the rescue. I assumed
that the hex-wide 8-slot backplane in the front of the card cage was the
original 11/40 processor backplane. On the back it says "LSI 11 BACKPLANE",
so the operation is not so mysterious. I had never seen a hex-wide Q-bus
backplane before this.

There are some pictures of the system and the Q-Bus to 11/40 front panel
interface here: http://www.ricomputermuseum.org/Home/equipment/dec-pdp-1140

-- 
Michael Thompson

Re: Leaking DEC VR201 monochrome monitor?

[Seth Morabito]

* On Wed, Jun 22, 2016 at 09:42:25AM -0700, Ian Finder  
wrote:
> Well, screen rot. Why didn't you say so in the first place!
> 
> The nasty substance that you came into contact with is almost certainly the
> decomposed RTV silicone leaking out.
> 
> Gross stuff.


Seconded and thirded. This is exactly what the problem is.

One of my ADM-3a terminals had an identical issue with the broken down
adhesive between the CRT and the implosion protection screen. It
leaked down onto the motherboard and it was only cured by fixing the
screen rot.

If I remember correctly, I used both isopropyl alcohol and Goo Gone
(citrus adhesive remover) to clean up the spilled gunk.

-Seth

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

[dwight]

> Are they general purpose, no…they require specialized > programming to 
> perform the computations.  But the HPC > (high performance
> computing) guys will do what it takes (and have for > decades) to get 
> the most out of the HW.


I have a friend that works for NSA that does just that.

Dwight



From: cctalk  on behalf of Guy Sotomayor Jr 

Sent: Wednesday, June 22, 2016 4:54:04 PM
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 Jun 21, 2016, at 11:07 PM, dwight  wrote:
>
> 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.

Having worked for both of those companies, I can also state the the number of 
people doing the high level design/architecture of
these chips is measured in the 100’s.  Most of the time the architects (I was 
one) write documentation in excruciating detail as to how
something is to work (and why) to be handed off to the design team(s) to 
actually implement.  In many ways it would’ve just been
easier/faster to write “code” but it’s harder for others to really know the 
why’s and wherefore’s and make sure that everything is worked
out properly before hand (on one new chip we literally spent *months* working 
out all of the details for the various reset and power
management flows…and that was just the docs describing how it should be done…no 
implementation).

>
> 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.

If the book were several 1000 pages.  ;-)

>
> 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.

The issue is that (much like many of the earlier supercomputers) is that they 
are vector processors.  Today’s supercomputers have a
(large) number of general purpose cores (ie POWER, x86) but they are there to 
manage the real work horses which are based on graphics chips.  It turns out 
that modern graphics chips have enormous FP capabilities.  For example, 
NVIDIA’s newest/baddest GPU
can do 10.6TFLOPS of single precision FP (using 3584 processors on the die).  
Now multiply by 100’s of GPUs that are put into modern super computers.

Are they general purpose, no…they require specialized programming to perform 
the computations.  But the HPC (high performance
computing) guys will do what it takes (and have for decades) to get the most 
out of the HW.

TTFN - Guy

Re: Now OT - Re: CDC 6600 - Why so awesome?

[Swift Griggs]

On Wed, 22 Jun 2016, Toby Thain wrote:
> Do you have a counterproposal? What problem do you think UTF-8 is trying 
> to solve?

Oh, heck no! I don't have any wish to wade into that particular swamp full 
of alligators. I have no counterproposal and as far as "what problem is 
UTF-8 trying to solve?" my repsonse is "too many at once."

> > People who
> > complain about twos-compliment being a weird hack ...
> I haven't heard that particular complaint. Got a cite?

Just some internet bungholes on reddit. Brother, just remember, *you* 
asked, and you can never get the time back:

https://www.reddit.com/r/programming/comments/d92jj/why_computers_use_twos_complement_to_represent/

-Swift

RE: CDC 6600 - Why so awesome?

[Swift Griggs]

On Wed, 22 Jun 2016, Rich Alderson wrote:
> We have one running at LCM, attached to an instance of dtCyber, the 
> 6000/Cyber simulator, via John Zabolitzky's Xilinx-based display 
> adapter.  We're in the process of refurbing the one that came with the 
> 6500, which we may attach to the system at some point.

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

> Not a matter of "didn't bother with", but rather "were never allowed 
> to". You don't get to fuck with the console of a multimillion dollar 
> machine if you're not part of the operations or systems programming 
> staff.

Like I was saying with Chuck, I just wasn't thinking about that, but it 
makes total sense when you put the $$$ into perspective.

> For the same reason you do it in the PDP-6/PDP-10:  Data often comes in 
> the form of text characters, which are much smaller than the word size, 
> so it makes sense to pack them in.

I get it. I just wondered about the mechanics of it.

> On the 6/10, the common method was 7-bit ASCII packed 5 per word. [...] 

Everyone had some whack-a-doodle way to encode character sets back then 
(and now it's just as bad or worse with things like UTF-8). People who 
complain about twos-compliment being a weird hack should focus more on all 
the ways folks encoded their charset. That's a veritable cornucopia of the 
arbitrary.

> ADJBP (ADJust Byte Pointer, which can back up as well as move forward).  

I find that weird, but possibly useful once I figured out how to implement 
it. Did that morph into something else as the platform matured or newer 
microcode hit the deck?

> The networking code uses a lot of 8- and 16-bit byte pointers, to handle 
> the fields in IP datagrams.

Convenient in this case, for sure. Hehe, not as convenient as me calling 
bind(), connect(), and send(), but hey apples to oranges, I know. :-)

> Other I/O code uses other byte sizes, to pull out or set the relevant 
> parts of device register values.

Well, I'd think it'd be helpful with I/O related code to deal with the 
real-world constellation of block devices from different devices. You 
could ratchet up when you needed throughput, and back down when you needed 
lower latency and finesse.
 
> A quick example, which substitutes a space for a rubout in a text string 
> without having to copy it into a second:
> 
> txtptr: point 7,string  ; sets up to point to the non-existent byte
> ; before string
> 
> move  10,txtptr ; initialize pointer in loop
> top:ildb  11,10 ; increments pointer, copies byte into AC 11
> skipn 11; non-null value?
>  jrst bottom; no, end of string, exit loop
> caie  11,177; is it a rubout character
>  jrst top   ; no, get next character in string
> movei 11,40 ; change a rubout to a space
> dpb   11,10 ; deposit byte into same location it came from
> jrst  top   ; and continue
> bottom: 

Ah. labels are grand, and yes no extra register or buffer needed!

> PDP-10 operating systems in general use null-terminated strings.

You mean the way $DIETY intended? :-)

> Hope that helps you with capital wrapping.

Har! These days folks let the MS Paper Clip do that!

-Swift

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

[Eric Smith]

On Wed, Jun 22, 2016 at 11:43 AM, Rich Alderson
 wrote:
> Does the scanner have a setting to do row-major vs. column-major
> scanning?  I ask from experience:  When I was putting Tops-10 v6.03A
> on our 1070, I had to have a fiche listing of VMSER.MAC scanned to
> PDF.  As you know, DEC FS fiche sheets are column-major, but the PDF
> came back to me row-major.  I had to print it out on 11x17 to reorder
> the pages for typein.
>
> Later, when I had the time, I used Acrobat to reorder the pages in
> the PDF, but that was also a major PITA.

If need be, I'll write a program for Al to automatically transpose the
page ordering of the PDF.

Re: CDC 6600 - Why so awesome?

[Swift Griggs]

On Wed, 22 Jun 2016, Chuck Guzis wrote:
> You don't seem to realize how expensive these systems were to operate. 

I'm sure I don't (but hey! give me credit for trying). I'm betting that 
even "expensive" systems of today (barring ultra-massive HPC SSI rigs) are 
cheap by comparison in inflation-adjusted dollars. I'm 41. I was born in 
the mid-70's and it was awfully time consuming afterwards learning 
pre-requisites to my computing skills, such as they are. Things like 
talking, correct potty techniques etc.. :-) Time I could have spent 
mainframin' if I'd only been taller. :-)

Plus, I have all kinds of different experiences "coming up", as it were. 
Somewhere near my moment of conscious singularity, it was the age of the PC 
and the micro. Sure, mainframes were (and kinda still are) going strong. 
Even for guys who lived it in the 1960's, they didn't grow up with 
computers around the house I'm betting. So, it's a bit of a shift in our 
thinking.

> IIRC, the *internal* COMSOURCE price charged for an hour of block time 
> was about $500 (that's 1970s dollars, thank you--when $3K would buy you 
> a nice imported sports car).

Hmm, and you'd want an imported one if it was the 1970s. Ugh. The drugs 
might have been good and the women more friendly, but the cars were a drag 
vis-a-vis the 1960s, OMG... What happened The 1980's weren't too much 
better (but I have soft spot for Fieros at least).

> There *was* a PP program called o26 (after the keypunch) but used mostly 
> by CEs and systems installation people.  Using the console of such an 
> expensive machine by ordinary users would have been viewed as something 
> akin to feeding $20 bills into a regular keypunch.

Hmm, I totally didn't consider that, but certainly seems like the kind of 
way people would act around something so valuable and expensive. I guess 
my "altar of the console" phrase wasn't so bad, then (ie.. half true).

> Remember, this was in the era of "glass walled rooms", where only 
> selected people were allowed to touch the machine.

Well, I started with computing very early, too. So, nowadays when I see 
those rooms I'm normally in the priesthood and am _expected_ to go fix 
some very expensive systems (I've put hands on production Origin 3k's, a 
couple of UNICOS based Cray systems, lots more). So, I kinda forgot about 
the outsider perspective, too. With many fewer systems around to work 
with, I'm sure the glass-walled sort of exclusivity got that much more 
serious.
 
> I once made the mistake of trying to mount my own tape at a military 
> base.  I thought that I was going to be tackled and led away by MPs. 
> They have people stationed by each bank of tape drives who do nothing 
> but that all day.  They don't take kindly to someone trying to take 
> their job.

LOL, there's initiative and there's orders. You had initiative. They 
had orders. 
 
> You don't understand.  Big iron did multitasking and multiprogramming, 
> but the I/O media was cards, tape and printed output.  Going "online" 
> was expensive and slow in terms of equipment.

Hmm, but wouldn't being able to multitask and multiprocess lead directly 
to wanting to have multiple terminals, card readers, tape readers, etc..? 
Then wouldn't someone be responsible for setting process priorities and 
managing the process scheduling? I told you I was an igmo on this. All I 
have to go on are sketchy internet archives that don't give me a sense of 
the real way these systems were used by real people.  The only other 
source about mainframes I had growing up was my grandmother, whom I 
worshiped as a child and worked on IBM gear. However, who knows what kind 
of kid-brained-notions I have grown into some personal fiction since then.

> The rolled-out job didn't lose its files or place in the running job 
> queue; it just got represented by a placeholder bit of memory (usually 
> the exchange package) and then read back in when its turn came up.

Ohhh, okay. That makes sense.

> Sometimes the non-classified parts were repurposed.

Some were, yes, and you cite some great examples. I'm just saying I'm more 
in favor of dumping bazillions of dollars on projects that more or less 
default into the public domain rather than default into top secret and 
someone has to justify having them released or shared. SDI in the 1980s 
sticks in my craw, I suppose. Unless of course they were secretly very 
successful and, in that case, I say "awesome"! I am strongly in support of 
not getting nuked!

> Who do you think Seymour Cray sold to as his initial customers for his 
> boxes?

Fair point. I'm not anti-military, but the NSA I'd like to see behave more 
responsibly.

> There was a lesson to be learned from it--give the I/O to another, 
> cheaper, machine.  You'll see that philosophy in the later Cray 
> machines.

I've noticed with really large systems they have some very interesting 
points of cleavage (just like their sales force, hehe). They split things 
up in ways that micros just 

Re: CDC 6600 - Why so awesome?

[Paul Berger]

On 2016-06-22 10:12 PM, Paul Koning wrote:

On Jun 22, 2016, at 8:40 PM, Fred Cisin  wrote:

Which was the first machine to have an optical card reader (V brass roller)?

For card based data processing, such as what my father did for Office Of Civil 
Rights, that speed improvement made a big difference.

I'm not sure why that would make it faster.  I've only seen brass roller 
reading in an IBM card sorter, which ran probably as fast as, if not faster 
than, than the fastest card reader I've ever seen.

paul

The sorter only read one column at a time, IBM also made a very fast 
punch/ reader the 2540 comes to mind, it could  1000 cards a minute and 
it still used brushes.  It read the card sideways into an 80 bit wide 
buffer and clocked the card data out the "normal" way on the channel.


Paul

Re: CDC 6600 - Why so awesome?

[Paul Koning]

> 
> On Wed, 22 Jun 2016, Chuck Guzis wrote:
> ...
>> Its illegitimate relative, KRONOS, made extensive use of ECS for support 
>> of the PLATO system. 

Not quite.  KRONOS treated ECS (rather clumsily) as a kind of disk.  PLATO just 
bypassed all that and managed ECS directly, as memory the way it was originally 
designed to be used.  After startup, PLATO would own all the ECS and do 
transfers directly, without any OS involvement.  It would also use ECS for 
inter-job communication, and for communication with PPU programs.  For example, 
PLATO disk I/O uses both request queues and data buffers in ECS, which the PPU 
program accesses.  Ditto for terminal I/O.

This is how PLATO could support 600 logged in highly interactive users on a 
pair of 6500 (low end 6000 series, single issue) machines.

paul

Re: CDC 6600 - Why so awesome?

[Paul Koning]

> On Jun 22, 2016, at 7:15 PM, Chuck Guzis  wrote:
> 
> ...
>> Could you roll them back in by just re-populating memory with the
>> dump and hooking back to whatever the equivalent of PC and EIP were
>> on that system and re-launching the job?
> 
> The rolled-out job didn't lose its files or place in the running job
> queue; it just got represented by a placeholder bit of memory (usually
> the exchange package) and then read back in when its turn came up.

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

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

paul

Re: CDC 6600 - Why so awesome?

[Paul Koning]

> On Jun 22, 2016, at 8:40 PM, Fred Cisin  wrote:
> 
> Which was the first machine to have an optical card reader (V brass roller)?
> 
> For card based data processing, such as what my father did for Office Of 
> Civil Rights, that speed improvement made a big difference.

I'm not sure why that would make it faster.  I've only seen brass roller 
reading in an IBM card sorter, which ran probably as fast as, if not faster 
than, than the fastest card reader I've ever seen.

paul

Re: CDC 6600 - Why so awesome?

[Fred Cisin]

Which was the first machine to have an optical card reader (V brass 
roller)?


For card based data processing, such as what my father did for Office Of 
Civil Rights, that speed improvement made a big difference.

BCPL, early TCP/IP, etc - was Re: Programming for the Alto's Mesa

[Toby Thain]

On 2016-06-21 3:42 PM, Ian S. King wrote:

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



BCPL was also the language of the very first implementations of TCP/IP.

ref 
https://www.quora.com/In-what-programming-language-was-TCP-IP-written/answer/Tony-Li-19


--Toby

FSOT: 9-slot VME backplane

[David Griffith]

I have a 9-slot VME backplane for sale or trade.  It weighs about 3 pounds 
when packed.  Pictures at 
https://www.flickr.com/photos/32548582@N02/albums/72157670027920776


--
David Griffith
d...@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/22/2016 04:46 PM, Rich Alderson wrote:

> And it's rarely an armload.  Most programs fit into a deck of a few dozen
> cards or so.  If you can't wrap a rubber band around the deck, you kept it
> in the box.  (Oh, yeah, you bought cards in boxes of 2000.  About 16" long,
> IIRC.)

Well, if you were a serious programmer, major segments of code came in
the drawer of a card filing cabinet (I don't recall exactly, but I
believe one held about two boxes.)  However, then the idea was to get
them onto tape before something dreadful happened, such as being
subjected to a jam or being rejected because of a compare error in the
reader.

I can recall on more than one occasion where an I/O clerk with a cart
loaded down with card trays hit a loose trim strip in a raised floor.
Mayhem indeed.  If you were smart, you drew a long diagonal across the
top of the card deck with a felt-tip pen to at least give you some sort
of clue about the order.

There were SCCS type of systems even back then.   SCOPE had UPDATE,
which corresponded to KRONOS MODIFY.  Each card was assigned a set
identifier and sequence number, used as reference when editing.  Updates
could be YANKed or PURGEd as necessary.

--Chuck

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

[jwsmobile]

I have access to an xyzprint Da Vinci Jr, which can't do very large 
files, but I'd be able to do PLA material with it.


the model my friend has doesn't do ABS.   BTW, I don't think because you 
3d print it that it is low cost.  If I am following the size of the 
part, the printing will be pretty lengthy unless you use a fast 
printer.  I'm not familiar with material cost quantity without the STL 
files I can't get any estimates on the time to print it.  Or if it will 
fit on this small printer.


I'm willing to borrow it, as both my buddy and I have been too lazy to 
spend the time to go the last mile to hook it up and make something, and 
try this if it fits.


thanks
Jim

On 6/20/2016 6:20 AM, martin.heppe...@dlr.de wrote:

Hi,



So I designed a replica case for 3D printing, but did not yet try it out.


Regards,
Martin

Martin {.} Hepperle {at} mh-aerotools {dot} de

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

[Guy Sotomayor Jr]

> On Jun 21, 2016, at 11:07 PM, dwight  wrote:
> 
> 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.

Having worked for both of those companies, I can also state the the number of 
people doing the high level design/architecture of
these chips is measured in the 100’s.  Most of the time the architects (I was 
one) write documentation in excruciating detail as to how
something is to work (and why) to be handed off to the design team(s) to 
actually implement.  In many ways it would’ve just been
easier/faster to write “code” but it’s harder for others to really know the 
why’s and wherefore’s and make sure that everything is worked
out properly before hand (on one new chip we literally spent *months* working 
out all of the details for the various reset and power
management flows…and that was just the docs describing how it should be done…no 
implementation).

> 
> 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.

If the book were several 1000 pages.  ;-)

> 
> 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.

The issue is that (much like many of the earlier supercomputers) is that they 
are vector processors.  Today’s supercomputers have a
(large) number of general purpose cores (ie POWER, x86) but they are there to 
manage the real work horses which are based on graphics chips.  It turns out 
that modern graphics chips have enormous FP capabilities.  For example, 
NVIDIA’s newest/baddest GPU
can do 10.6TFLOPS of single precision FP (using 3584 processors on the die).  
Now multiply by 100’s of GPUs that are put into modern super computers.

Are they general purpose, no…they require specialized programming to perform 
the computations.  But the HPC (high performance
computing) guys will do what it takes (and have for decades) to get the most 
out of the HW.

TTFN - Guy

RE: CDC 6600 - Why so awesome?

[Rich Alderson]

From: Swift Griggs
Sent: Wednesday, June 22, 2016 1:58 PM

On Wed, 22 Jun 2016, Chuck Guzis wrote:

>> I think Paul's covered that pretty well.  I'll add that the more complex
>> the display, the more flicker was present.

> The descriptions are fascinating. I hope I can see one operating some day. 
> Do you know of any still operational ?

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

>> Well, SCOPE had INTERCOM, an interactive facility, as well as 
>> EXPORT/IMPORT which was an RJE facility.  But the system was targeted 
>> primarily at batch jobs.

> Hmm, after reading the responses, I'm guessing most folks just showed up 
> with an armload of punch cards and didn't bother with keying things on the 
> console at the altar of the system.

Not a matter of "didn't bother with", but rather "were never allowed to".
You don't get to fuck with the console of a multimillion dollar machine if
you're not part of the operations or systems programming staff.

And it's rarely an armload.  Most programs fit into a deck of a few dozen
cards or so.  If you can't wrap a rubber band around the deck, you kept it
in the box.  (Oh, yeah, you bought cards in boxes of 2000.  About 16" long,
IIRC.)

>> As an aside, take a look at the UNIVAC 1107/1108 instruction set from 
>> roughly the same period.  It has an instruction to define the byte size 
>> (36 bit words).

> Hmm, interesting. I can't really even wrap my head around the implications.
> If you can't change the register sizes, why would you want to do that?  Was
> it just to shorten certain operations by increasing or decreasing their width?

For the same reason you do it in the PDP-6/PDP-10:  Data often comes in the
form of text characters, which are much smaller than the word size, so it makes
sense to pack them in.

On the 6/10, the common method was 7-bit ASCII packed 5 per word.  With
instructions for operating on byte pointers available, you set your initial
pointer up such that an increment will end up pointing at the first byte in a
word; Macro-10 had a pseudo-op for doing that (or pointing at any other byte in
the word, depending on what you needed to do).  In addition to the byte size
and location within the word, the indexed and/or indirected address of the word
is in the one-word byte pointer.

The most commonly used instructions are ILDB (Increment pointer and LoaD Byte
into AC) and IDPB (Increment pointer and DePosit Byte); there are also LDB and
DPB (good for status-checking operations, for example), IBP (Increment Byte
Pointer), and on the KL-10 and later processors, ADJBP (ADJust Byte Pointer,
which can back up as well as move forward).  If the byte size is such that no
room is left in the current word, the first byte in the next word in memory is
addressed.

The networking code uses a lot of 8- and 16-bit byte pointers, to handle the
fields in IP datagrams.  Other I/O code uses other byte sizes, to pull out or
set the relevant parts of device register values.

A quick example, which substitutes a space for a rubout in a text string
without having to copy it into a second:

txtptr: point 7,string  ; sets up to point to the non-existent byte
; before string

move  10,txtptr ; initialize pointer in loop
top:ildb  11,10 ; increments pointer, copies byte into AC 11
skipn 11; non-null value?
 jrst bottom; no, end of string, exit loop
caie  11,177; is it a rubout character
 jrst top   ; no, get next character in string
movei 11,40 ; change a rubout to a space
dpb   11,10 ; deposit byte into same location it came from
jrst  top   ; and continue
bottom: 

PDP-10 operating systems in general use null-terminated strings.

Hope that helps you with capital wrapping.

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?

[Eric Smith]

On Wed, Jun 22, 2016 at 5:15 PM, Chuck Guzis  wrote:
> You don't understand.  Big iron did multitasking and multiprogramming,
> but the I/O media was cards, tape and printed output.  Going "online"
> was expensive and slow in terms of equipment.

There were many people who saw timesharing as a huge waste of
resources, even though the better timesharing systems were actually
quite efficient. (And the timesharing systems often simultaneously ran
batch jobs.)

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

[dwight]

I guess we are talking apples and oranges. I'm not talking

chip that can be implemented in tiny sizes. I'm talking chips of the complexity

of current Intel and AMD chips. The instruction decode and its effect are a 
small

part of the overall size. The ARM64 is an example of poorly implemented RISC.

They put too much of the legacy stuff into it.

Dwight



From: cctalk  on behalf of Paul Koning 

Sent: Wednesday, June 22, 2016 9:01:56 AM
To: General Discussion: On-Topic and Off-Topic Posts
Cc: j...@mercury.lcs.mit.edu
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for 
unknown ICs?


> On Jun 22, 2016, at 9:15 AM, Noel Chiappa  wrote:
>
>> From: Dwight Kelvey
>
>> The RIS[C]/CISC is really not even relevant in todays processors since
>> the main limiting factor is memory access bandwidth and effective use
>> of caches.
>
> Memory bandwidth has often been the limiting factor over the complete
> timeline of CPU's/systems. (It would be interesting to draw up a timeline,
> showing the periods when it was, and was not.) Yes, caches can help a lot,
> but inevitably they will miss (depending on the application, more or less
> often).

I can't think of an obvious example where memory speed wasn't a concern.  
Possibly a reason is that memory would be tailored to the rest of the system 
(cheaper lower cost core if the CPU didn't need it faster).  But, for example, 
making the memory run well is a large part of why the 6600 looks the way it 
does.

> The RISC/CISC thing actually is kind of relevant to this, because RISC
> focuses on getting the CPU cycles to be as fast as possible, and that kind of
> implies simpler instructions --> more instructions to get a particular task
> done.

One consideration is that a RISC CPU requires vastly less silicon.  So you can 
do RISC in very small/cheap chips, or on a larger chip spend far less on the 
CPU core and leave more room (at constant die cost) for other stuff like caches 
or auxiliary components.  One place you can see this is in the various MIPS or 
ARM based "system on a chip" products, which have some CPU cores plus memory 
controllers, cache, UARTs, I/O buses, flash interfaces, crypto cores, RAID 
coprocessor cores, etc. etc.  Or you might find chips with very large core 
counts, like the Tilera 100-core processors.  (For that matter, the DECmpp 
many-core machine was a RISC machine for the same reason.)

paul

Re: CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/22/2016 01:58 PM, Swift Griggs wrote:

> Hmm, after reading the responses, I'm guessing most folks just showed
> up with an armload of punch cards and didn't bother with keying
> things on the console at the altar of the system.

You don't seem to realize how expensive these systems were to operate.
IIRC, the  *internal* COMSOURCE price charged for an hour of block time
was about $500 (that's 1970s dollars, thank you--when $3K would buy you
a nice imported sports car).   There *was* a PP program called o26
(after the keypunch) but used mostly by CEs and systems installation
people.  Using the console of such an expensive machine by ordinary
users would have been viewed as something akin to feeding $20 bills into
a regular keypunch.   Remember, this was in the era of "glass walled
rooms", where only selected people were allowed to touch the machine.

I once made the mistake of trying to mount my own tape at a military
base.  I thought that I was going to be tackled and led away by MPs.
They have people stationed by each bank of tape drives who do nothing
but that all day.  They don't take kindly to someone trying to take
their job.

> Well, it probably didn't need to do much multi-process multi-tasking,
> so that probably still worked out fine vis-a-vis the competition.

You don't understand.  Big iron did multitasking and multiprogramming,
but the I/O media was cards, tape and printed output.  Going "online"
was expensive and slow in terms of equipment.

> Could you roll them back in by just re-populating memory with the
> dump and hooking back to whatever the equivalent of PC and EIP were
> on that system and re-launching the job?

The rolled-out job didn't lose its files or place in the running job
queue; it just got represented by a placeholder bit of memory (usually
the exchange package) and then read back in when its turn came up.

> I'm not fond of them. They waste a ton of money (classified budget!?)
> on projects that never see the light of day. I contrast their efforts
> with folks like NASA where a lot of (amazing and super important)
> tech found it's way to the public domain. I would cheer to see them
> de-funded, renamed, and irrelevant.

Sometimes the non-classified parts were repurposed.  For example,
TCM/TOOS was used for both USAF Logistics and UBS (Switzerland)
projects.   Called different things, of course and code shared only up
to a point.

Remember that SAGE was classified.  The military and defense industries
were major funders of big iron work.  Who do you think Seymour Cray sold
to as his initial customers for his boxes?

> Hehe, isn't that always the way it goes. Version 2 is always much
> harder to get right.

There was a lesson to be learned from it--give the I/O to another,
cheaper, machine.   You'll see that philosophy in the later Cray machines.

> Sure it can. I've done that on the M68k before, too. It's a mechanism
> I've used for to create more complex mechanisms. Rotate with carry
> was something I often found useful, too, since I could use the carry
> bit for a conditional jump.

The 6000 had no carry bits; for that matter, it had no condition codes
at all. If you think about it, that makes instruction scheduling much
easier because you don't have to worry about instruction side-effects.
On the X (60 bit registers), you can branch on the sign of a register or
its zero/nonzero contents. B-registers can be queried by a single
compare and branch instruction. It also helps that the 6000 is a
three-address architecture, so you needn't clobber a source register
when testing contents. And the smallest instruction was only 15 bits wide.

> Hmm, interesting. I can't really even wrap my head around the 
> implications. If you can't change the register sizes, why would you
> want to do that ? Was it just to shorten certain operations by
> increasing or decreasing their width ?

To elaborate a bit, you could divide a word into sixths, halves and
thirds (6, 18 and 12 bit) parcels and operate on each of them.  So not
really a "byte".

> That's a pretty micromanaging standard, though (I skimmed it). I can
> just see some style-nazi jerkhole in the back with the guide
> nitpicking everyone's comma placement. "How DARE you put a space
> before the comma on the destination operand!" *apoplectic choke*.
> Still, I've had gigs where there was no style guide and it can create
> stress and friction between coders. So, I guess it's better to have
> one than to just have the wild west. Otherwise, you'll give people a
> pass who want to show you how clever than can be in various extremely
> annoying ways. In C, it's usually someone who thinks it's cool to use
> one-letter variables for everything, and make all his lines 180
> columns long. I've never had to peer review someone's ASM. It'd be
> pretty painful, I think.

It was a necessary evil with long product lives, many people, etc.
"Egoless coding".  Try doing something else and you wind up with Linux
code eventually.   Miles of code 

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

[Jay West]

A listmember who is quite adept at 3d printing has agreed to give it a shot.
Did someone say they had a parts file to try out?

J 

Re: WTD: S100 Static RAM card

[Mike Stein]

Hi Philip,

Just going through some old emails; did you find a suitable card?

m
- Original Message - 
From: "Philip Lord" 
To: "General Discussion: On-Topic and Off-Topic Posts" 
Sent: Friday, March 27, 2015 12:16 AM
Subject: Re: WTD: S100 Static RAM card


Well, maybe I’m too cheap, but some of the ebay prices just seem crazy. 
Hopefully I can find something at a more reasonable price. If not, then I guess 
I’ll have to bite the bullet. Those Econoram boards look nice and simple, but 
those RAM16 and RAM 17 boards look like the real deal.

Andrew’s board certainly looks nice, but if it did need modifying to work in 
the IMSAI, I’m guessing I wouldn’t have the skill to do it. Unfortunately.
Also everyone has their own philosophy on retro computing, mine is that I’d 
actually like to keep the systems as close to “period" as possible. Putting a 
modern RAM/ROM board in the IMSAI doesn’t fit my philosophy. 

Thanks again for all the suggestions.



> On Mar 27, 2015, at 12:41 PM, Mike Stein  wrote:
> 
> Maybe you could adapt one of John & Andrew's boards?
> 
> http://s100computers.com/My%20System%20Pages/PROM%20Board/PROM%20Board.htm
> 
> m
> - Original Message - From: "Philip Lord" 
> To: "General Discussion: On-Topic and Off-Topic Posts" 
> Sent: Thursday, March 26, 2015 6:30 PM
> Subject: Re: WTD: S100 Static RAM card
> 
> 
> Hi Mike,
> Well it’s certainly nice to know the Cromemco is also another good option if 
> I want to try DRAM again, but I am feeling that a good SRAM card maybe a 
> safer option, and possibly easier for me to repair if anything goes wrong.
> 
> Thanks for your thoughts
> 
>> On Mar 27, 2015, at 10:32 AM, Mike Stein  wrote:
>> 
>> FWIW I've never had any problems with Cromemco 64KZ-II DRAM cards.
>> 
>> m
>> 
>> - Original Message - From: "Philip Lord" 
>> To: ; "General Discussion: On-Topic and Off-Topic 
>> Posts" 
>> Sent: Thursday, March 26, 2015 5:19 PM
>> Subject: Re: WTD: S100 Static RAM card
>> 
>> 
>> Hi Jim, thanks for the info.
>> Always good to know what people think are good cards, and what aren’t.
>> 
>> Cheers
>> 
>> 
>>> On Mar 27, 2015, at 10:13 AM, Jim Stephens  wrote:
>>> 
>>> 
>>> 
>>> On 3/26/2015 1:34 PM, Philip Lord wrote:
 Hi all,
 I’ve been struggling getting a 64k Dynamic RAM card back up and working in 
 my IMSAI 8080. In fact I’m giving up on the DRAM card in this system and 
 have decided to start looking for a SRAM card that can get the IMSAI up to 
 56k.
 
 In terms if SRAM cards, I presently have:
 
 2 x Problem solver RAM16 cards - both seem to be working.
 2 x 8K RAM cards - both seem to be working.
 
 Less cards generating heat, and putting stress on the old power supply is 
 obviously best, so I’d be looking for either:
 
 - 1 x 16k SRAM card (for a total of 4 RAM cards (3 x 16k + 1 x 8k) in my 
 system). A PSS RAM16 would be preferred for sake of consistency, but 
 obviously not crucial.
 - 1 x 32k SRAM card (for a total of 3 RAM cards (1 x 32k, 1 x 16k + 1 x 
 8k) in my system)
 - 1 x 64k SRAM card that can have the last 8k bank turned off
 
 I would love to hear from anyone with one of the above cards who would be 
 willing to pass it on.
 
 Much thanks for your time.
 
 Best regards
 
 Philip
>>> I do not have any to pass on, but in the day, you couldn't do better than 
>>> IMS 16k's  I also had a Tarbell CPU with 256k of Dram, and that was the 
>>> only dynamic ram I ever had in an S100 system.
>>> 
>>> Also if you can find Compupro, I suspect it is as likely to be perfect as 
>>> the IMS boards are.
>>> 
>>> Thanks
>>> Jim
>> 
> 

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

[Jürgen Keller]

I don't have a 3D printer, however, I'm interested in a replica case, too.

Jurgen

Am 20.06.2016 um 15:20 schrieb martin.heppe...@dlr.de:

> Hi,
> 
> I own PRM-85 boards for my HP-85 and 86 machines. While they are very useful 
> extension modules for these computers, they lack a proper case. I hate to 
> destroy a working interface or memory module just for the case.
> I read in this list that there are more people interested in such a case.
> 
> So I designed a replica case for 3D printing, but did not yet try it out.
> 
> I do not own a 3D printer and the commercial services calculate between $20 
> to $100 for one shell (upper/lower).
> This is a bit expensive for some trials, as I expect that the 3D design would 
> need some iterative refinement to obtain a "perfect" case.
> 
> 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. As a "thank-you" I would expect feedback to 
> improve the design.
> 
> Regards,
> Martin
> 
> Martin {.} Hepperle {at} mh-aerotools {dot} de
> 

Re: CDC 6600 - Why so awesome?

[Swift Griggs]

On Wed, 22 Jun 2016, Chuck Guzis wrote:
> I think Paul's covered that pretty well.  I'll add that the more complex
> the display, the more flicker was present.

The descriptions are fascinating. I hope I can see one operating some day. 
Do you know of any still operational ?

> >> Much of the architectural concept was shared with IBM 7030 STRETCH 
> >> (another system worth researching).
> > Hmm, I've never heard of it. I'll check it out. Thanks. 
> Do check it out--there was some bleeding-edge technology that went into
> that system that was later used by Cray in his 6600. 

So far my only comment on the Stretch is "I also hate project managers." 

> One of those project that could be said to be a technical success, but a 
> financial fiasco.

I'm always happy to see corporations lose (scads of) money for a good 
cause. Hmm, now that I think about it, it doesn't even need to be a good 
cause. :-)

> Well, SCOPE had INTERCOM, an interactive facility, as well as 
> EXPORT/IMPORT which was an RJE facility.  But the system was targeted 
> primarily at batch jobs.

Hmm, after reading the responses, I'm guessing most folks just showed up 
with an armload of punch cards and didn't bother with keying things on the 
console at the altar of the system.

> Its illegitimate relative, KRONOS, made extensive use of ECS for support 
> of the PLATO system.  Note that the 6000 series had no hardware memory 
> management to speak of. 

Well, it probably didn't need to do much multi-process multi-tasking, so 
that probably still worked out fine vis-a-vis the competition.

> An active job had a relocation address (RA) and field length (FL), but 
> memory space belonging to a job was contiguous and present in physical 
> memory (no paging or segmentation).  So jobs were moved or "rolled out" 
> to mass storage as needs for resources arose.

Could you roll them back in by just re-populating memory with the dump and 
hooking back to whatever the equivalent of PC and EIP were on that system 
and re-launching the job?

>  So that was for standard offerings--"special systems" (i.e. spooks) had 
> their own adaptations, probably still classified today.

I'm not fond of them. They waste a ton of money (classified budget!?) on 
projects that never see the light of day. I contrast their efforts with 
folks like NASA where a lot of (amazing and super important) tech found 
it's way to the public domain. I would cheer to see them de-funded, 
renamed, and irrelevant. 

> However, there was more than one SCOPE--and when reading the bitsavers 
> stuff, you have to be careful.

Ah, okay, good to know.

> So SCOPE 2 was developed for the 7600.  In it, PPs are relegated to I/O
> and (one very special unit) for maintenance.

Awww, darn. I thought that was pretty cool about the 6600, actually. Time 
marches on, I guess.

>  The operating system proper resides in a set of "nested" program units.  
> That is, there would, for example be a Buffer Manager with an RA and FL 
> that encompassed the Record Manager program, which, in turn would 
> encompass the Job Supervisor...and eventually the user program itself.  

Thanks for that description, that helps a lot, actually. I'm an "applied" 
guy and I'm not very imaginative when it comes to theoreticals. So, 
knowing the nuts and bolts operational stuff helps me to understand how 
the abstract parts fit together.

> A system of "rings of protection" if you will, long before that was in 
> vogue. Although bulk core (LCM = large core memory; the 7600 term for 
> 6000 ECS) was used as program storage,

> [...] the whole affair turned out to be more cumbersome than originally 
> envisioned.  The SCOPE 2 folks were always a little defensive about this 
> result of necessity.

Hehe, isn't that always the way it goes. Version 2 is always much harder 
to get right.

> CDC was sharply split in culture as well as geography--the Minnesota 
> clan was cut from different cloth than the Palo Alto-then-Sunnyvale 
> clan, so discussions from the West coast tend to be more SCOPE-oriented, 
> while the pickled watermelon rind clan talks fondly about KRONOS.

Interesting! I really like little tidbits like this when I'm piecing 
together a "system narrative" again, it puts some things in perspective. 

> Working with full words and shifting and masking can be remarkably 
> efficient. 

Sure it can. I've done that on the M68k before, too. It's a mechanism I've 
used for to create more complex mechanisms. Rotate with carry was 
something I often found useful, too, since I could use the carry bit for a 
conditional jump.

> I recall the "what do we do about more than 64 characters" discussion 
> was raging.  One interesting alternative proposed was to fit 7.5 8-bit 
> characters to the word, with the odd 4-bit leftover being called a 
> "snaque" (snaque-byte; get it?).

Hehe, clever. 

> Instead what was done was to reserve some of the lesser used characters 
> of the 64-character set as "escape" codes for what amounts to 

Re: CDC 6600 - Why so awesome?

[Noel Chiappa]

> From: Brian Walenz

>> Werner Buchholz (editor), "Planning a Computer System: Project
>> Stretch", McGraw-Hill, New York, 1962

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

Yeah, I found that _after_ I sent the email, sigh...

>> Speaking of books, there's also a CDC 6600 book:
>>   Jim E. Thornton, "Design of A Computer: The Control Data 6600",
>> Scott, Foresman, Glenview, 1970

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

Didn't know that one was online too - excellent.


>> Really gotta do that Bibliography!

> Where is this 'computer history wiki', anyway?

http://gunkies.org/wiki/Main_Page

Note; automatic account creation is disabled to prevent spamming issues. You
have to email Tore directly - and he is often busy, so it may take a bit.

Noel

Re: Data General 8000-series logic in my Nova 3?!

[Mark J. Blair]

> On Jun 22, 2016, at 12:31 , shad  wrote:
> 
> Hello Mark,
> when you are ready with your machine up and running,
> you could try to use on a real Nova 3 the tool I wrote to raw read/write 
> disks and tapes through the serial port.
> You just need a PC (linux preferred) and Python installed (plus serial port 
> module).

I forgot about your disk dumper tool! I was planning to write my own, but maybe 
I don't need to now!


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Data General 8000-series logic in my Nova 3?!

[Mark J. Blair]

> On Jun 22, 2016, at 12:29 , Jay West  wrote:
> 
> Mark wrote...
> =
> Additional documentation is flowing in behind the schematic courtesy of that
> little birdie who all of us DG collectors know and love
> =
> 
> Here Birdie Birdie (throwing sunflower seeds on the ground)

LOL! I assume that you already know this birdie, but I'll be happy to hook you 
up if not.

Have you determined whether any of your 6030 floppy drives are "extra"? If not, 
I think that there's exactly the right amount of open rack units in my DG rack 
to hold my PDP-8/M and a mil-surplus Chalco high speed paper tape reader I have 
that could be fun to interface to the PDP-8 and/or the Nova. But if I'll be 
hosting a 6030 drive in the rack then I'll need to come up with a different 
plan!


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

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

[Noel Chiappa]

> From: Al Kossow aek at bitsavers.org 

> which one?
> 1974_Field_Service_Technical_Manual_Dec74.pdf
> is already on line under handbooks

Dat be de one. Alas for the OP, it doesn't seem to contain any PDP-11 stuff
(well, a bit on the RK11-C, etc, but nothing on any processor, at least that
I could see).

FWIW, it's available online on an indexed, page-by-page basis at:

  http://www.pdp8online.com/bklatt/TechTips.html

Worth looking through.

Some of them are amusing, like "Disk Destruction Made Simple" and "DECtape
Reels Falling Off Drive".

Noel

library/book carts available

[Jay West]

Maybe a year ago I got two metal 3 shelf library carts on wheels, to hold
the manuals that were related to whatever machine I was working on at the
time. Its extremely useful to have all the manuals at hand on a rolling
stand when you're moving around working on the beast. I have not seen any
for sale since then at a reasonable price (which I'd say is $100 or less).

 

I just stopped at a place here in St. Louis, and I see they have 8 of these
"library/book carts" available. They are basically in mint condition, and
most of them come with old red binders on 2 of the 3 shelves. The binders
are interesting - these are those old ones with sort of cloth surfaces and
heavy metal latches inside. All the binders are about 3 or 3.5 inch wide. A
typical place I see these type of binders is in machine shops and the like,
holding press setup instructions and such. The binders are old, but the
carts are basically new looking. The carts are 42.5" tall, 31" wide, and 13"
deep. The carts hold books on one side only, and the height of each shelf
between the next is 11 & 5/8. If your binders are taller than that they
won't fit ;) $75 each.

 

Here is a link to an almost-but-not-quite-identical cart:
http://tinyurl.com/huamv7e

 

I'm buying 2 of these for myself, leaving six. I'd be happy to purchase and
hold for a while if someone non-local wants some, but it's probably not
economical to ship them. I could deliver one or two to VCFMW this year
perhaps.

 

J

 

 

Re: Data General 8000-series logic in my Nova 3?!

[shadoooo]

Hello Mark,
when you are ready with your machine up and running,
you could try to use on a real Nova 3 the tool I wrote to raw read/write 
disks and tapes through the serial port.
You just need a PC (linux preferred) and Python installed (plus serial 
port module).


Then you should be able to dump the disk to image for SIMH, and 
eventually to write back an image to the disk.


Thanks
Andrea

RE: Data General 8000-series logic in my Nova 3?!

[Jay West]

Mark wrote...
=
Additional documentation is flowing in behind the schematic courtesy of that
little birdie who all of us DG collectors know and love
=

Here Birdie Birdie (throwing sunflower seeds on the ground)

J

RE: Leaking DEC VR201 monochrome monitor?

[tony duell]

> (one tip: I used a silicone-based double-stick gel-like "tape" to
> remount the implosion protector (with an air gap) because the naked
> CRT didn't fit the VT220 housing well enough to make me happy - I'd
> approach the VR201 restoration with the same expectation).

As far as I know, the front of an implosion-protected CRT works
like a laminated windscreen (windshield). There are 2 (normal) 
glass layers bonded together by the 'goo'. If you've refitted the
outer layer with just fixing tape at the edges, you do not have
any implosion protection. And I certainly would not sit in front
of a CRT like that!

-tony

Re: Leaking DEC VR201 monochrome monitor?

[william degnan]

>
>
> > >
> > > If it does come from inside, just about the only thing it can be is
> > > electrolyte from one of the capacitors. I'd remove the case [1] and
> > > have a look.
> > > Possibly
> > > wearing gloves...
> > >
>
>
> Nasty! I have a couple of working VR201s that I want to check for
> impending problems, this has prompted me to plan to do that sooner rather
> than later.
>
> Regards
>
> Rob
>
>


The skin under my index finger is still a little sore.  ouch.

Re: Leaking DEC VR201 monochrome monitor?

[Ethan Dicks]

On Wed, Jun 22, 2016 at 10:49 AM, william degnan  wrote:
> I picked up a DEC VR201 display today, it was leaking a highly corrosive
> brown liquid.  So corrosive it burned my skin painfully /  immediately and
> I had to wash hands thoroughly.  Anyone come across a display that leaked a
> corrosive liquid like that?  The display was stored in its original box, so
> I don't think the brown liquid was from something stored on top of it, but
> I don't know for sure.

I've had brown liquid emit from a VT220 - I think it was the goo
between the CRT and the implosion shield decomposing.  I tore it all
apart and cleaned it and put it back in service (it was my first VT220
from 1984...)  It's a messy job.  I happen to have working guts of a
VR201 from when I dropped one and busted the CRT 20 years ago... if
you don't want to deal with the cleanup/refurb, I can always use
another VR201 (to replace the broken one!).  PM me.  If you want to do
it yourself, it can be done, but it's a multi-night project, I'd say
(one tip: I used a silicone-based double-stick gel-like "tape" to
remount the implosion protector (with an air gap) because the naked
CRT didn't fit the VT220 housing well enough to make me happy - I'd
approach the VR201 restoration with the same expectation).

-ethan

RE: Leaking DEC VR201 monochrome monitor?

[Rob Jarratt]

> -Original Message-
> From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of william
> degnan
> Sent: 22 June 2016 16:42
> To: General Discussion: On-Topic Posts 
> Subject: Re: Leaking DEC VR201 monochrome monitor?
> 
> On Wed, Jun 22, 2016 at 11:10 AM, tony duell 
> wrote:
> 
> > > I picked up a DEC VR201 display today, it was leaking a highly
> > > corrosive brown liquid.  So corrosive it burned my skin painfully /
> > > immediately
> > and
> >
> > Ouch, in more ways than one. If it attacks your skin like that, I
> > wonder what it has done to the insides of the monitor.
> >
> > > I had to wash hands thoroughly.  Anyone come across a display that
> > leaked a
> > > corrosive liquid like that?  The display was stored in its original
> > > box,
> > so
> > > I don't think the brown liquid was from something stored on top of
> > > it,
> > but
> > > I don't know for sure.
> >
> > If it does come from inside, just about the only thing it can be is
> > electrolyte from one of the capacitors. I'd remove the case [1] and
> > have a look.
> > Possibly
> > wearing gloves...
> >


Nasty! I have a couple of working VR201s that I want to check for impending 
problems, this has prompted me to plan to do that sooner rather than later.

Regards

Rob

Re: Leaking DEC VR201 monochrome monitor?

[Ian Finder]

Well, screen rot. Why didn't you say so in the first place!

The nasty substance that you came into contact with is almost certainly the
decomposed RTV silicone leaking out.

Gross stuff.

On Wednesday, June 22, 2016, william degnan  wrote:

> On Wed, Jun 22, 2016 at 11:10 AM, tony duell  >
> wrote:
>
> > > I picked up a DEC VR201 display today, it was leaking a highly
> corrosive
> > > brown liquid.  So corrosive it burned my skin painfully /  immediately
> > and
> >
> > Ouch, in more ways than one. If it attacks your skin like that, I wonder
> > what
> > it has done to the insides of the monitor.
> >
> > > I had to wash hands thoroughly.  Anyone come across a display that
> > leaked a
> > > corrosive liquid like that?  The display was stored in its original
> box,
> > so
> > > I don't think the brown liquid was from something stored on top of it,
> > but
> > > I don't know for sure.
> >
> > If it does come from inside, just about the only thing it can be is
> > electrolyte
> > from one of the capacitors. I'd remove the case [1] and have a look.
> > Possibly
> > wearing gloves...
> >
> > [1] Very easy on the VR201. Extend the 'leg' fully. Put the unit
> > screen-side
> > down. Prise (pry) off the circular cap on the back, over the screw. Undo
> > that
> > screw (#2 phillips). Slide off the case.
> >
> > -tony
> >
>
>
> The screen rot is so bad, I am not sure I even want to mess with it.
> --
> @ BillDeg:
> Web: vintagecomputer.net
> Twitter: @billdeg 
> Youtube: @billdeg 
> Unauthorized Bio 
>


-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: Leaking DEC VR201 monochrome monitor?

[Ian Primus]

Yes. It's the PVA compound leaking out of the picture tube, from
between the faceplate and the tube itself. I see this on lots of
terminals and monitors. You need to remove the picture tube, heat the
faceplate and separate it from the tube, and clean up all the brown
goop, and put everything back together. It's corrosive, and it will
eat traces (this is a big problem on ADM3A terminals, since the goo
leaks onto the circuit board).

This is definitely fixable.

-Ian

On Wed, Jun 22, 2016 at 10:49 AM, william degnan  wrote:
> I picked up a DEC VR201 display today, it was leaking a highly corrosive
> brown liquid.  So corrosive it burned my skin painfully /  immediately and
> I had to wash hands thoroughly.  Anyone come across a display that leaked a
> corrosive liquid like that?  The display was stored in its original box, so
> I don't think the brown liquid was from something stored on top of it, but
> I don't know for sure.
>
> Bill
>
> --
> @ BillDeg:
> Web: vintagecomputer.net
> Twitter: @billdeg 
> Youtube: @billdeg 
> Unauthorized Bio 

Re: Leaking DEC VR201 monochrome monitor?

[Swift Griggs]

On Wed, 22 Jun 2016, william degnan wrote:
> I picked up a DEC VR201 display today, it was leaking a highly corrosive 
> brown liquid.  So corrosive it burned my skin painfully / immediately 
> and I had to wash hands thoroughly.

PH test it, if you can. If it's caustic, then I'd suspect condensate mixed 
with electrolytic capacitor gunk. If it's acidic, I'd suspect either an 
industrial cleaner or again condensate that had mixed with acid from 
solder flux, then partially evaporated, leaving a concentrated acid ready 
to burn you. That's my cockamamie theory. 

If it tests acidic, put on some gloves and eye protection and pull the 
boards out you can, leaving just the (discharged) tube and the case. Then 
flush everything with a mix of water and baking soda. If it's caustic, 
clean it out with vinegar (ie.. 3% diluted acetic acid). Then flush the 
whole thing with purified water, clean the boards, and reassemble it. It 
might be a lost cause if that stuff has got down into the flyback 
transformer or ate all the solder mask off your logic board.

-Swift

Leaking DEC VR201 monochrome monitor?

[william degnan]

I picked up a DEC VR201 display today, it was leaking a highly corrosive
brown liquid.  So corrosive it burned my skin painfully /  immediately and
I had to wash hands thoroughly.  Anyone come across a display that leaked a
corrosive liquid like that?  The display was stored in its original box, so
I don't think the brown liquid was from something stored on top of it, but
I don't know for sure.

Bill

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: Leaking DEC VR201 monochrome monitor?

[william degnan]

On Wed, Jun 22, 2016 at 11:10 AM, tony duell 
wrote:

> > I picked up a DEC VR201 display today, it was leaking a highly corrosive
> > brown liquid.  So corrosive it burned my skin painfully /  immediately
> and
>
> Ouch, in more ways than one. If it attacks your skin like that, I wonder
> what
> it has done to the insides of the monitor.
>
> > I had to wash hands thoroughly.  Anyone come across a display that
> leaked a
> > corrosive liquid like that?  The display was stored in its original box,
> so
> > I don't think the brown liquid was from something stored on top of it,
> but
> > I don't know for sure.
>
> If it does come from inside, just about the only thing it can be is
> electrolyte
> from one of the capacitors. I'd remove the case [1] and have a look.
> Possibly
> wearing gloves...
>
> [1] Very easy on the VR201. Extend the 'leg' fully. Put the unit
> screen-side
> down. Prise (pry) off the circular cap on the back, over the screw. Undo
> that
> screw (#2 phillips). Slide off the case.
>
> -tony
>


The screen rot is so bad, I am not sure I even want to mess with it.
-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: Leaking DEC VR201 monochrome monitor?

[Paul Koning]

> On Jun 22, 2016, at 10:49 AM, william degnan  wrote:
> 
> I picked up a DEC VR201 display today, it was leaking a highly corrosive
> brown liquid.  So corrosive it burned my skin painfully /  immediately and
> I had to wash hands thoroughly.  Anyone come across a display that leaked a
> corrosive liquid like that?  The display was stored in its original box, so
> I don't think the brown liquid was from something stored on top of it, but
> I don't know for sure.

Electrolytic capacitor?  That's about the only component I can think of you'd 
find in a monitor that might contain corrosives.  (Batteries also do, but a 
VR201 is not likely to contain one.)

paul

Re: Leaking DEC VR201 monochrome monitor?

[Liam Proven]

On 22 June 2016 at 16:49, william degnan  wrote:
> I picked up a DEC VR201 display today, it was leaking a highly corrosive
> brown liquid.  So corrosive it burned my skin painfully /  immediately and
> I had to wash hands thoroughly.  Anyone come across a display that leaked a
> corrosive liquid like that?  The display was stored in its original box, so
> I don't think the brown liquid was from something stored on top of it, but
> I don't know for sure.


Capacitor electrolyte?

-- 
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: where to find DEC ECO's for KB11-A?

[Al Kossow]

On 6/22/16 10:43 AM, Rich Alderson wrote:
> From: Al Kossow
> Sent: Wednesday, June 22, 2016 7:42 AM
> 
>> good a time as any to mention this..
> 
>> I bought a step and repeat fiche scanner a couple of months ago
>> and am going to start scanning the thousands of sheet backlog I
>> have, once I get all the fiche in one place and dedup it. ECO-LOGs
>> are definitely in there (have several DEC PDP-xx 'blue boxes')
> 
> Hi, Al,
> 
> Does the scanner have a setting to do row-major vs. column-major
> scanning?

It is column major, taking about 6 passes length wise, stepping the image
sensor down the rows.

It's a Wicks & Wilson FS300 like this:
http://www.ebay.com/itm/252408866998

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

[Al Kossow]

On 6/22/16 9:02 AM, Noel Chiappa wrote:

> I have a DEC Field Circus handbook arriving today

which one?

1974_Field_Service_Technical_Manual_Dec74.pdf
is already on line under handbooks

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

[Rich Alderson]

From: Al Kossow
Sent: Wednesday, June 22, 2016 7:42 AM

> good a time as any to mention this..

> I bought a step and repeat fiche scanner a couple of months ago
> and am going to start scanning the thousands of sheet backlog I
> have, once I get all the fiche in one place and dedup it. ECO-LOGs
> are definitely in there (have several DEC PDP-xx 'blue boxes')

Hi, Al,

Does the scanner have a setting to do row-major vs. column-major
scanning?  I ask from experience:  When I was putting Tops-10 v6.03A
on our 1070, I had to have a fiche listing of VMSER.MAC scanned to
PDF.  As you know, DEC FS fiche sheets are column-major, but the PDF
came back to me row-major.  I had to print it out on 11x17 to reorder
the pages for typein.

Later, when I had the time, I used Acrobat to reorder the pages in
the PDF, but that was also a major PITA.

Just thinking of you.

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: cctalk Digest, Vol 24, Issue 22

[Michael Thompson]

>
> Date: Tue, 21 Jun 2016 18:08:49 -0700
> From: Glen Slick 
> Subject: Re: PDP-11/40 modified to be a PDP-11/23
>
> What boards exactly? Are you sure it's not an M7133 11/24 board instead?
>
> From front to back in the AB slots:

   - M8186, KDF11-A, 11/23 CPU, 18-bit addressing only
   - M8044-DM, MSV11-DD, 32-Kword 16-bit MOS RAM
   - M8043, DLVJ1-M, 4-Line Asynchronous Interface
   - M7940, DLV11, Serial Line Unit (SLU, Async)

A custom interface to the front panel is in the CD connectors of the first
slot.

I will post pictures of the boards on the RICM WWW site.

-- 
Michael Thompson

Re: CDC 6600 - Why so awesome?

[Brian Walenz]

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

   Werner Buchholz (editor), "Planning a Computer System: Project Stretch",
> McGraw-Hill, New York, 1962
>

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


> Speaking of books, there's also a CDC 6600 book:
>
>   Jim E. Thornton, "Design of A Computer: The Control Data 6600",
> Scott, Foresman, Glenview, 1970
>

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

(apologies for using the non-official link)

Really gotta do that Bibliography!
>
> Noel
>

Ah, that's why my googling around the other day failed!  The current pace
of recommended books is already quicker than I can read.  Where is this
'computer history wiki', anyway?

b

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

[Fritz Mueller]

Thanks a lot, folks!

And of course, thanks so much Al for bitsavers -- the DEC archives 
there, for me at least, have made this whole hobby possible!


I have an early (serial 152) 11/45 that I've been restoring.  Just now 
to the point in CPU debug where I can reliably toggle in and run simple 
programs.  Next step will be to get some serial I/O going so I can 
conveniently load some more thorough diagnostics and be sure the CPU and 
memory are completely shaken out.  Then on to working on storage.


I have a pretty complete set of CPU spares, but they are of various 
different revisions, having differing sets of green wires etc.  I'd like 
to have a look at the ECOs at some point so I can properly sort out and 
record what is what, and/or possibly bring all the boards up to a 
consistent level.


cheers,
--Fritzm.

Re: Data General 8000-series logic in my Nova 3?!

[Mark J. Blair]

> On Jun 22, 2016, at 08:55, William Donzelli  wrote:
> 
>> I'm feeling so happy that I think I'll buy my dogs a cheeseburger at 
>> In-N-Out on the way home tonight to celebrate.
> 
> Just one? Or do you want a dog fight?

Little dog gets 1/3, and bigger dog gets 2/3. That's the In-N-Out prescribed 
dosage; for McDonald's, it's 1/2 for little dog, 1 for big dog, and 1/2 for me 
(plus the Quarter Pounder I already ate) since their cheeseburgers are smaller.


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

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

[Paul Koning]

> On Jun 22, 2016, at 9:15 AM, Noel Chiappa  wrote:
> 
>> From: Dwight Kelvey
> 
>> The RIS[C]/CISC is really not even relevant in todays processors since
>> the main limiting factor is memory access bandwidth and effective use
>> of caches.
> 
> Memory bandwidth has often been the limiting factor over the complete
> timeline of CPU's/systems. (It would be interesting to draw up a timeline,
> showing the periods when it was, and was not.) Yes, caches can help a lot,
> but inevitably they will miss (depending on the application, more or less
> often).

I can't think of an obvious example where memory speed wasn't a concern.  
Possibly a reason is that memory would be tailored to the rest of the system 
(cheaper lower cost core if the CPU didn't need it faster).  But, for example, 
making the memory run well is a large part of why the 6600 looks the way it 
does.

> The RISC/CISC thing actually is kind of relevant to this, because RISC
> focuses on getting the CPU cycles to be as fast as possible, and that kind of
> implies simpler instructions --> more instructions to get a particular task
> done.

One consideration is that a RISC CPU requires vastly less silicon.  So you can 
do RISC in very small/cheap chips, or on a larger chip spend far less on the 
CPU core and leave more room (at constant die cost) for other stuff like caches 
or auxiliary components.  One place you can see this is in the various MIPS or 
ARM based "system on a chip" products, which have some CPU cores plus memory 
controllers, cache, UARTs, I/O buses, flash interfaces, crypto cores, RAID 
coprocessor cores, etc. etc.  Or you might find chips with very large core 
counts, like the Tilera 100-core processors.  (For that matter, the DECmpp 
many-core machine was a RISC machine for the same reason.)

paul

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

[Noel Chiappa]

> From: Fritz Mueller fritzm at fritzm.org 

> Are DEC ECO's available online anywhere? ... I am particularly
> interested in ECO's related to the KB11-A (11/45).

I have a DEC Field Circus handbook arriving today that allegedly contains
some ECO information; if there's anything on the KB11-A, I'll see if I can
get it scanned.

Noel

Re: CDC 6600 - Why so awesome?

[Noel Chiappa]

> From: Swift Griggs

>> Much of the architectural concept was shared with IBM 7030 STRETCH
>> (another system worth researching).

> Hmm, I've never heard of it. I'll check it out. 

The first supercomputer, IMO. It's an interesting machine, with a variety of
innovations that later became standard: e.g. it has separate instruction and
arithmetic units, with the former being in charge of all fetches, both
instruction and data, as well as executing things like branch instructions;
it also has a primitive form of pipelining ("Interlocks in the look-ahead
unit ensure that nothing is altered permanently until all the preceeding
instructions have been executed successfully.")

Eric has a nice page about it:

  https://www.brouhaha.com/~eric/retrocomputing/ibm/stretch/

There's a good book about it:

   Werner Buchholz (editor), "Planning a Computer System: Project Stretch",
McGraw-Hill, New York, 1962

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

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


Really gotta do that Bibliography!

Noel

Re: Data General 8000-series logic in my Nova 3?!

[William Donzelli]

> I'm feeling so happy that I think I'll buy my dogs a cheeseburger at In-N-Out 
> on the way home tonight to celebrate.

Just one? Or do you want a dog fight?

--
Will

Re: CDC 6600 - Why so awesome?

[Paul Koning]

> On Jun 22, 2016, at 11:32 AM, Swift Griggs  wrote:
> 
> On Tue, 21 Jun 2016, Chuck Guzis wrote:
>>> - It had some wicked cool "demos", to cop a C64 term. (ADC, PAC, EYE)
>> Those were mostly toys to amuse the CEs, like the baseball game BAT.
> 
> I was trying to find some video of one of those actually running. I wanted 
> to see how the "calligraphic displays" painted the graphics. Do you happen 
> to know why they went with two displays like that? Did the two have 
> different purposes?

The displays could do vector-drawn text ("calligraphic") or arbitrary graphics 
by drawing dots (basically just periods).  No line vectors.  Plot speed was 
about 2.5 microseconds per character.  The displays did not have any kind of 
refresh memory -- instead, the controlling software would just redisplay stuff 
fast enough.  This meant that your status display was always up to date, 
because it was rebuilding the display from the current state each refresh.  
This is very handy to get a feel for what a system is doing.  For example, if 
something gets stuck, the corresponding display element would freeze.  If 
things were running, that element might flicker or be a blur.  You'd get the 
same intuitive view of stuff as you do with a classic "lights" console (only 
more so).

Text could be displayed in three sizes; the smallest characters were 64 across, 
32 lines, per tube.  I suspect one reason for two tubes is the same reason that 
people today put two displays on their desk: more screen real estate to show 
more stuff.  Given the way the circuitry was done, two displays were only 
slightly more expensive than one.  The controller would send the signals to the 
tube pairs, and a tube select signal would control which tube would light up 
for that particular signal.  So things like the character waveform generator 
did not have to be duplicated.

I've seen some photos but haven't run into videos.  There's an emulation that 
fairly accurately shows what things looked like; one could do screen capture 
videos from that.  But that wouldn't be quite the real thing.

> ...
>> It had several *cool* OSes, but really only two major ones for general 
>> consumption (Special Systems Dvision had several more).  SCOPE (later 
>> NOS/BE), pretty much initially a PP-resident OS based on the old 
>> Chippewa Operating System--and NOS (was KRONOS, originally MACE),
> 
> I tried to find some info on SCOPE, but it's very sparse. Did it have an 
> interactive command line? What was your main "interface" to the OS? 

They all started out as batch (card deck input), unless you count job entry 
from the console display which was for operator use.  Remote Job Entry showed 
up in some of them, as did timesharing.  The early timesharing stuff was 
amazingly primitive but it worked.  Roughly speaking you'd enter the same 
commands as might appear in a card deck, but each would be executed when 
entered.

> ...
>> There aren't any alignment issues, since the CPU was only 
>> word-addressable.  This was when a character was 6 bits (think IBM 709x, 
>> UNIVAC 1100, etc.)  So a word with 10 characters was logical.
> 
> I figured it was something like that, but I'm so used to 8-bit bytes and 
> such. It takes a minute to adjust my thinking to a different base, but 
> it's not that hard.

Bytes, in the sense of 8 bit clumps that were addressable, showed up in the IBM 
360 series.  Before then, and for that matter in many other computers for years 
after, machines tended to be word addressable, and character sizes might vary.  
60 bits with 6 bit characters (usually) is one example.  36 bits with 6 or 7 or 
8 bits is another.  48 bits with 8 bit characters... the list goes on.  If you 
think these are odd, consider the Electrologica machines, with 27 bit words and 
5, 6, 7, or 9 bit characters.

paul

Re: CDC 6600 - Why so awesome?

[Swift Griggs]

On Tue, 21 Jun 2016, Chuck Guzis wrote:
> > - It had some wicked cool "demos", to cop a C64 term. (ADC, PAC, EYE)
> Those were mostly toys to amuse the CEs, like the baseball game BAT.

I was trying to find some video of one of those actually running. I wanted 
to see how the "calligraphic displays" painted the graphics. Do you happen 
to know why they went with two displays like that? Did the two have 
different purposes?

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

Most folks I know who were in their 20s or 30s in the 60s or 70s didn't, 
either. However, computer games were the "hook" that got a lot of people 
like me interested in computing as children. I instantly became more 
interested in creating the games, not just playing them. I've known a lot 
of others with the same sort of instincts.

> Much of the architectural concept was shared with IBM 7030 STRETCH 
> (another system worth researching).

Hmm, I've never heard of it. I'll check it out. Thanks. 

> > - It wasn't DEC and it wasn't IBM and it was faster than both when it hit 
> >   the street? 
> With a 10 MHz clock.

Impressive. 

> It had several *cool* OSes, but really only two major ones for general 
> consumption (Special Systems Dvision had several more).  SCOPE (later 
> NOS/BE), pretty much initially a PP-resident OS based on the old 
> Chippewa Operating System--and NOS (was KRONOS, originally MACE),

I tried to find some info on SCOPE, but it's very sparse. Did it have an 
interactive command line? What was your main "interface" to the OS? 

> started as a "bootleg" project by Greg Mansfield and (Dr.) Dave 
> Callender at Arden Hills.  (MACE stood for "(Greg) Mansfield's Answer to 
> Customer Engineering".

Lots of great and interesting operating systems start as a reaction to the 
status quo or some idea they find abhorrent. UNIX and many variants 
certainly have. Ie.. Ken & Dennis working on side-projects while bored and 
demotivated by Multics, BSD guys reacting to AT clamping down, Linus 
reacting to his profs, Theo forking NetBSD, I could go on and on...

UNIX: Born in rebellion.

> Most batch programs written for SCOPE would run fine on MACE with few, 
> if any, modifications.

Did Control Data sell both or was one from an alternative vendor?

>  In retrospect, CDC keeping two operating systems (SCOPE was part of CPD 
> in Sunnyvale, while KRONOS stayed home in Arden Hillls) was probably a 
> strategic blunder, since much duplicate effort was wasted.  Eventually, 
> the two were merged into NOS (for Network Operating System).

I found this PDF:

http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/nos/60435400J_NOS_Version_1_Reference_Volume_1_Aug79.pdf

It's interesting to me because of how "different" everything is. I'm not 
well versed in mainframe operating systems. It's interesting.

> There aren't any alignment issues, since the CPU was only 
> word-addressable.  This was when a character was 6 bits (think IBM 709x, 
> UNIVAC 1100, etc.)  So a word with 10 characters was logical.

I figured it was something like that, but I'm so used to 8-bit bytes and 
such. It takes a minute to adjust my thinking to a different base, but 
it's not that hard.

> Given that PP words 12 bits (5 to a CM word) and there were 10 PPUs, 
> each executing at a speed 1/10th the CPU, it had a very pleasant sort of 
> symmetry.

I suppose it doesn't matter as long as things factor out properly: no 
worries.

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

Well, the sample code I could find was particularly well put together by 
someone who knew they were doing. I'm a pretty poor ASM programmer, since 
the only one I ever put much effort into was for the M68k (which is really 
easy compared to some).  I've got a big crush on MIPS ASM but I never was 
any good with it. C ruined me. :-)

> > ... Is super-readable, in fact, probably a bit more than several 
> > much-newer dialects on different platforms. There was one instruction 
> > "PROTECT" I found pretty interesting, too. 
> Where did you find that?  I've never heard of such an instruction.

I was mistaken, it's only a control statement for COMPASS. It's actually 
in the PDF manual I was just looking at. It's used to "preserve a user's 
ECS field length between job steps."

-Swift

Re: Data General 8000-series logic in my Nova 3?!

[Noel Chiappa]

> From: Mark J. Blair

> An interface card schematic has appeared in my inbox as if by magic.

If that allows you to create a list of what various 8000-series chips do (or
if you've since located one), that would be a good thing to have available
online. If you have (or create) one, we can stick it on the Computer History
wiki...

Noel

Re: old friend is slimming down the warehouse

[Mark J. Blair]

> On Jun 22, 2016, at 07:23, Todd Killingsworth  
> wrote:
> 
> I'm set up to go onsite this afternoon, and I've got new SD cards and two
> batteries for the camera.  Once I've figured out a good place to post them,
> I'll pass the link along.   I think this is more of a corporate/enterprise
> collection so I'm not expecting SGI - but he's got a lot of stuff.
> 
> You never know what you'll find on this kind of run..Should be fun!

I'm looking forward to seeing what you find!


> On Jun 21, 2016, at 13:05, William Donzelli  wrote:
> 
> Be sure to tell your friend that the mainframe collectors can
> certainly make cubic feet of equipment leave the warehouse quickly!

In case it helps any mainframe collectors, I just checked, and ramen noodle 
soup costs around $0.41 per meal on Amazon Prime. I'm still working on the 
problem creating more cubic feet^H^H^H^Hyards of available volume in a small 
house, though.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

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

[Mark J. Blair]

> On Jun 22, 2016, at 07:42, Al Kossow  wrote:
> 
> good a time as any to mention this..
> 
> I bought a step and repeat fiche scanner a couple of months ago
> and am going to start scanning the thousands of sheet backlog I
> have, once I get all the fiche in one place and dedup it. ECO-LOGs
> are definitely in there (have several DEC PDP-xx 'blue boxes')

That's great news, Al! Thanks for doing this stuff. It's a great service to 
collectors and computer historians of the present and the future.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Data General 8000-series logic in my Nova 3?!

[Mark J. Blair]

Update! An interface card schematic has appeared in my inbox as if by magic. 
That changes this task from "breaking the enemy cipher" to plain ol' logic 
debugging. Woohoo!


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

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

[Al Kossow]

good a time as any to mention this..

I bought a step and repeat fiche scanner a couple of months ago
and am going to start scanning the thousands of sheet backlog I
have, once I get all the fiche in one place and dedup it. ECO-LOGs
are definitely in there (have several DEC PDP-xx 'blue boxes')


On 6/22/16 12:47 AM, Paul Anderson wrote:
> Field service used to get them on micro fiche. I might have some here
> somewhere, but it may take a while to look.
> 
> Newer print sets could have info on the older ones.
> 
> Paul
> 
> On Tue, Jun 21, 2016 at 4:25 PM, Fritz Mueller  wrote:
> 
>> 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.
>>

RE: CDC 6600 - Why so awesome?

[Swift Griggs]

On Tue, 21 Jun 2016, Rich Alderson wrote:
> > - 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?

Exactly, yes. I was thinking that 60 bits is not divisble by 8. However, 
as I said, I'm a total ignoramous about the platform. 

> The word is [...] ... packed into the 60-bit word.
> Where would you see alignment issues?

Well, as you so eloquently explain, as long as the units feeding into the 
registers are factors of the register's total size, it's not a problem. 
So, it sounds like it wasn't an issue. I didn't know of any actual issue, 
I was just curious.

-Swift

Re: old friend is slimming down the warehouse

[Todd Killingsworth]

I'm set up to go onsite this afternoon, and I've got new SD cards and two
batteries for the camera.  Once I've figured out a good place to post them,
I'll pass the link along.   I think this is more of a corporate/enterprise
collection so I'm not expecting SGI - but he's got a lot of stuff.

You never know what you'll find on this kind of run..Should be fun!

Todd Killingsworth

On Wed, Jun 22, 2016 at 10:17 AM, Connor Krukosky  wrote:

> +1 You tell em Will!
>
> -Connor K
>
> On Jun 21, 2016 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: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?

[Noel Chiappa]

> From: Dwight Kelvey

> The RIS[C]/CISC is really not even relevant in todays processors since
> the main limiting factor is memory access bandwidth and effective use
> of caches.

Memory bandwidth has often been the limiting factor over the complete
timeline of CPU's/systems. (It would be interesting to draw up a timeline,
showing the periods when it was, and was not.) Yes, caches can help a lot,
but inevitably they will miss (depending on the application, more or less
often).

The RISC/CISC thing actually is kind of relevant to this, because RISC
focuses on getting the CPU cycles to be as fast as possible, and that kind of
implies simpler instructions --> more instructions to get a particular task
done.

That was part of the motivation for microcoding, back when it was invented; at
that point in time, logic was fast, memories were slow, so more complex
instructions made better use of memory bandwidth - especially since this was
pre-caches. (It also made binary code 'denser', which was important back then,
with much smaller memories.) However, more complex instruction sets made the
CPU more complicated; microcoding helped deal with that.

The 801's breakthrough, at a very high level, was to see the whole system,
and try and optimize across the compiler as well as the instruction set, etc,
etc. They also realized that people had been going CISCy for so long that
people had to some degree forgotten why, and that that assumption needed to
be re-examined - especially in light of the then-current logic/memory speed
balance, which had shifted towards memory at that particular point in time.

Noel

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

[Paul Anderson]

Field service used to get them on micro fiche. I might have some here
somewhere, but it may take a while to look.

Newer print sets could have info on the older ones.

Paul

On Tue, Jun 21, 2016 at 4:25 PM, Fritz Mueller  wrote:

> 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.
>

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.
>>
>