🚀 go-pugleaf

In article <93...@asylum.SF.CA.US> karl@asylum.UUCP (Karl Auerbach) writes:
>The best set of blinkin' lights I ever saw on a computer was on an
>old SAGE machine, the Q32 (or was it the Q7?) -- the console was about
>15 feet long, 8 feet high and covered with switches, dials, and what-nots.

Several large pieces (if not the whole thing) of one of the SAGE machines
are on display in the Computer Museum at 300 Congress St. in Boston, MA.


James Purdon
pur...@cons1.mit.edu

In article <1990Jan2.1...@athena.mit.edu> pur...@athena.mit.edu (James R Purdon) writes:

   >The best set of blinkin' lights I ever saw on a computer was on an
   >old SAGE machine, the Q32 (or was it the Q7?) -- the console was about
   >15 feet long, 8 feet high and covered with switches, dials, and what-nots.

   Several large pieces (if not the whole thing) of one of the SAGE machines
   are on display in the Computer Museum at 300 Congress St. in Boston, MA.

And the lights still blink -- they went to some trouble to build a
discrete transistor driver for all those damn lights to blink in an
apparently meaningful way (that is, they blink in a pattern similar to
what would be generated if the machine was actually running.

Great museum -- go see it if you're in Boston!

Disclaimer:  former employee of the world's only museum dedicated to
computers.

--
--mike bergman
	      Massachusetts Microelectronics Center
	      75 North Drive, Westborough, MA  01581, USA +1 (508) 870-0312
	UUCP: (...harvard)!m2c!bergman    INTERNET:   ber...@m2c.org         

The nicest set of CPU lights I've seen were on the old Burroughs B6700;
there was a light for each bit in every register.  When the machine was
idle the processor lights spelled out IDLE; later they changed that to
show the big Burroughs B.  This was a 48-bit machine and we had the
dual-processor model - there were a LOT of lights on that beast.

The killer was that most of those lights were also pushbuttons and
pushing them set the bit in the associated register.  This could be
real interesting and make for bizarre system crashes, as we found out
one day whilst playing tennis in the computer room.  Seems that a flying
tennis ball has plenty enough force to activate several adjacent buttons
when it hits the processor console....

Whadday mean, HALT/LOAD for negative time of day?
	- Brian

In article <10...@ucsd.Edu> br...@ucsd.edu (Brian Kantor) writes:
>The nicest set of CPU lights I've seen were on the old Burroughs B6700;

>The killer was that most of those lights were also pushbuttons and
>pushing them set the bit in the associated register.  This could be


We had someone who would play Russian Roulette - you would halt the machine,
change a bit in a top of stack (A) register [tags didn't count] and see what
crashed .... not really a good idea

	Paul

-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
"Why is it that the US can invade Panama but not the Vatican Embassy?"
"1995 - The leader of the free-world? That would be Gorbachev ..."

In article <93...@asylum.SF.CA.US> karl@asylum.UUCP (Karl Auerbach) writes:
}The best set of blinkin' lights I ever saw on a computer was on an
}old SAGE machine, the Q32 (or was it the Q7?) -- the console was about
}15 feet long, 8 feet high and covered with switches, dials, and what-nots.
}
}I heard that a movie company bought one when the machines were scrapped.
}
}Other than that one, the IBM 360/91 had great lights.

My blinkenlights story concerns a machine at the Rockwell Avionics
Development Lab in Downey, CA. (Alas, 6 years of bit rot have deleted its
name from my head).  It was an oddball device used to simulate other
computer systems.  I think it must have had a lot of registers and an LED
for every bit in every one of them.  Using the LEDs as a banner sign was a
popular passtime.

-- 
The Polymath (aka: Jerry Hollombe, holl...@ttidca.tti.com)  Illegitimis non
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   (213) 450-9111, x2483
Santa Monica, CA  90405 {csun | philabs | psivax}!ttidca!hollombe

In article <446@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:
+
+We had someone who would play Russian Roulette - you would halt the machine,
+change a bit in a top of stack (A) register [tags didn't count] and see what
+crashed .... not really a good idea
+
 We used to play a game here called "Base-Bank Roulette".  The name  stems
from  the  memory  architecture  of the Quotron 801 machines that were/are
used for the main processor.  The machine has 4 op-registers  and  a  64KB
map,  48KB as the base bank, where the BasicOperatingSystem (BOS) resides,
and 16KB for the apps stuff to run in.  The trick was, the upper 16KB  was
bank-selectable;  hence by bliting the Bank Switch Register, an elementary
context-switch could be effected.

 Anyway, after writing the Trace Facility for our  DEBUGGER...Then,  after
rewriting the debugger..I got pretty good at at knowing which range of base
bank memory addresses would cause a crash.  The betting usually involved a
wager based on the new-contents. If you put a zero in, it would be an even
money bet..a NOP induced crash was worth 2x..Another form of this same kind
of sillyness was called "Patch Guess"..I install a patch, you guess what my
patch does. After a few months none of the Apps people would play with any
of the OS team...Hmmm...I wunder why? ;-)

 One of the best was a patch that became known as the "Sniveler's Patch"..
the machine has a (no shit!) Load-meter on the front panel, it's driven by
a simple 5vdc  line  and  can  be  switched  on  or  off  by  two  special
instructions; namely MON and MOF!

 Using the <mask> search feature of my new DEBUG, I discovered that  there
were ONE (and only ONE) of each! The idea was, that when the upper 16KB was
being accessed (or when there was other  NON-INTERRUPT  LEVEL  work  being
done) the meter was turned on.  It was turned off during interrupt level
processing; and so there was relative index of load..can  you  guess  what
happens next? :-)

 So I took a QA field test pack-set, and patched the base-bank to reverse the
the order of the MON/MOFs and sat back to watch the fun. Sure enough! One of
the QA people (a particularly disliked-by-the-OS-staffers QA person!) came in
to test a new Application...he loaded up and fired up a small configuration
of machines, all linked via async lines. Normally, when a transaction goes
"thru" you could watch the meter and "see" it happen, and then  the  meter
would "settle" to an idle...not this time! The meter went to 100% at the
startup (which it did normally, but only for a quick flash) and stayed there!

 The guy was freaked! The system  s e e m e d  ok...it was running...and when
a transaction went thru the load dropped...???  He scribbled a few notes and
split. I then changed the MON/MOF and rebooted, making sure to disable the
console TTY during the reboot...the QA guy returned with the Applications
developer in tow. What a riot!

 QA guy:"But-but, I *SAW* it! Honestly!......."

 Apps guy:"Nahhhh.....it's working fine...you must be hallucinating!"
  (stomps off)

 ..boy, those were the days! ;-)
-- 
-Avatar-> (aka: Erik K. Sorgatz) KB6LUY           +-------------------------+
Citicorp(+)TTI                          *----------> panic trap; type = N+1 *
3100 Ocean Park Blvd. Santa Monica, CA  90405     +-------------------------+
{csun,philabs,psivax,pyramid,quad1,rdlvax,retix}!ttidca!sorgatz **