🚀 go-pugleaf

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