-*- Mode:Text -*-
;;;
;;; (c) Copyright 1984 - Lisp Machine, Inc.
;;;

NOTES 11/28  RG + NGL
   INSTALLED MUCH LARGER CAP IN POWER CLEAR CIRCUIT.  NOW IT POWER CLEARS FOR
ABOUT A HALF SECOND AFTER POWER ON.

   WITH MI BOARD PLUGGED IN,  MI BOARD DOES NOT FOUL NUBUS INITIALLY ON POWER
ON, BUT DOES AFTER VARIOUS WRITES TO MODE REGISTER OR CONFIGURATION REGISTER.

   CONFIGURATION REGISTER POWERS UP 17 IN LOW ORDER 4 BITS, WHICH IS RIGHT SINCE
IN READS IN COMPLEMENTED.  WRITING 1 BIT LOW (TURNING ON NON-EXISTANT LED) CAUSES
NO PROBLEMS.  LIKEWISE 4 BIT (PICKING UP INIT).  WRITING 2 OR 10 BITS LOW CAUSES
DEATH, WHICH MAY BE REASONABLE.  (10 CAUSE NU-ISOLATE TO GO AWAY, 2 ENABLES LAMBDA
CLOCK WHICH REALLY SHOULD CAUSE SUCH LOSSAGE).

  WRITING 20 BIT TO PROCESSOR MODE REGISTER (MANUAL CLOCK) ALSO CAUSES DEATH.

FOUND THAT AFTER CLOCK, CACHE STATE MACHINE IS REQUESTING CYCLE FROM NUBUS PAL.
BETTER CLEAR CSM.REG SOON AFTER POWERUP, ETC.

  GEE. WE HAVE A PROBLEM.  YOU CANT ZERO TREG (THUS UNFOULING MFO) WITHOUT CLOCKING
MACHINE, BUT IF YOU DO, THE MI BOARD WILL KILL YOU.  YOU CANT DO ANYTHING TO
FIX THE MI BOARD WHILE THE MFO BUS IS GRONKED...
  FIX MAY BE TO SPLIT RESET LINE SO THAT MI BOARD CAN BE HELD RESET WHILE RG
BOARD IS INITIALIZED  (WHICH INVOLVES CLOCKING CLOCK, ETC.)

  BTW, SPY WRITES TO MI BOARD WERE OBSERVED TO PRODUCE WINNING WRITE PULSES, MODULO
THE FACT THE ADDRESS LINES ARE SWAPPED.  SOFTWARE (TEMPORARILY?) CHANGED TO COMPENSATE.


RE DATA PATH BOARD:
  GOOD CS AND WE OBSERVED OK ON M-MEM WHILE RUNNING UINST-M-COUNT-LOOP!

  DP.SOURCE.CYCLE OBSERVED NOT TO BE FROBBING.  WAS THAT GROUNDED OUT VIA
PUSH PIN AT SOME POINT??  CHECK RG BOARD...

11/29  DEXTER

	SWAPPED SELECTS ON SPY DECODE - TO AVOID FUTURE CONFUSION

	SEPARATE MI INIT IS A GOOD IDEA.  IN ADDITION, THE NUBUS-ISOLATE FACILITY
SHOULD BE MADE MORE COMPLETE, BLOCKING ANY ACCESS TO THE NUBUS. PERHAPS WE ALSO WANT
A SPECIFIC "CLEAR CSM REG" SIGNAL

11/30 rg
   noted apparent bad cram chip bits 44-47, bank 1.  Gee wouldn't it be nice to
be able to figure out which physical chip this was?  


   As I thought, two pairs of the 4 input selectors driving the alu control inputs
are supposed to be f353's not 253's (the difference being an inversion of the output).
These were supposed to be on order, we should get them pronto.  until then,
it is possible to compensate somewhat in software, although multiply and divide
wont work.
   However, there is still a bug in that the two halves of the "right-hand" selector
in the prints want opposite senses of the frob.  If we can get 353's, the easiest 
would be to add an inverter to fix.   -alu.carry.in which comes out in the wrong sense.

   If we cant get 353's, we can still make the machine work with a fairly small mod,
which would be to add three inverters to get -ir.alu.control.2, -ir.alu.control.3,
and -ir.alu.control.4.  The inputs on essentially three chips worth of selectors
would have to be rewired.  they are all constant grounds or hi s, so it would just
be swapping a ground where there is currently a hi and vice versa.  
   From a timing point of view, it doesnt make any difference which we do, since none
of these paths are time critical (the stuff is sitting there the entire source cycle
before this makes a difference during the execute cycle.).

   maybe we should just mod it to avoid using the 353s ....

12/4 -DEXTER

THE DP BOARD IS IN THE MIDDLE OF A MOD TO THE Q REGISTER, BUT SHOULD BE OTHERWISE
USABLE. MOST OF THE WRITE-FOO, READ-FOO FUNCTIONS ARE IN. RECOMPILE.

I'M WORKING ON THE MASKER PROM PROGRAM

12/4 -RG, TOMMY
	FIX - PUT IN AM.WRITE.ADDRESS MOD ON CM, BIT 6

	REMOVED SPURIOUS WIRE B30-12 TO B20-3.  THERE WAS SUPPOSED TO BE A WIRE TO
    C39-12, WHICH WAS THERE TOO.
        NOW "PASSES" FAST ADDRESS TEST A MEM, MODULO ALU BITS WHICH ARE PART-WAY MODDED NOW.

    HOWEVER, FAST ADDRESS TESTS DO SEEM TO HAVE SOME NON-REPRODUCABLE FLAKINESS,
    WHICH MIGHT WELL BE CAUSED BY SEMI-RANDOM MEMORY LOCATIONS GETTING WRITTEN DURING SUPPOSED
    READ CYCLES DUE TO LACK OF INHIBIT-WRITE-PULSE-MOD.
    
12/4 -DEXTER


first patching q reg mod ... even if Q doesn't work, it ought not to disrupt other
data paths - OK, ALU side done for that chip, no problem with data paths

added the inhibit write pulse mod, 'scoped the write pulse both with machine proceeded
and while sm-ticking it

looking at mi board, it now causes force t.hold to fail, sometimes unable to force uinst
clock low....

12/5 RG

  THE SCHEME FOR ORING CLOCKS TO MD REGISTER DOESNT WORK.  CAN GENERATE GLITCHY CLOCKS AS
THINGS LIKE UINST.DEST.MD (WHICH COME FROM PROM) SET UP DURING THE FIRST HALF CYCLE
WHILE UINST-CLOCK IS STILL HIGH.
  THE FIX SEEMS TO BE TO GENERATE A UINST-CLOCK L SIGNAL AND USE AN AND-OR-INVERT GATE
TO DO THE ORING.  THAT WAY, AS LONG AS UINST.DEST.MD, ETC, ARE STABLE BY THE END OF
THE FIRST HALF CLOCK CYCLE, ALL IS OK.
  CLEARLY, THE UINST-CLOCK L SIGNAL SHOULD BE GENERATED WITH AS LITTLE SKEW AS POSSIBLE
FROM UINST-CLOCK.  PROBABLY THE BEST WAY IS TO TAKE ONE SECTION OF THE 2 IN QUAD
LATCH ON THE RG BOARD WHICH GENERATES UINST-CLOCK, AND REVERSE THE INPUTS.
WE THEN ALLOCATE A NEW BACKPANEL WIRE TO UINST-CLOCK L.  TO FREE UP THE SECTION,
WE COMBINE 2 OF THE T.UINST.CLOCK.TO XX SIGNALS.  ACTUALLY, MAYBE BETTER IS TO COMBINE
ALL FOUR OF THEM, SINCE THE CLOCK IS BUFFERED IN THE SIGNAL BUFFER PRINT ON EACH BOARD
ANYWAY.  THEN WE NET WIND UP FREEING UP A BACKPLANE SIGNAL...

  ABOVE SCHEME IS PROBABLY HOW IT SHOULD BE DONE ON NEXT VERSION OF MACHINE, BUT FOR
NOW WE CAN WIN JUST AS WELL WITH A SMALLER MOD BY PUTTING T.UINST.CLOCK.TO.MI THRU
AN INVERTING BUFFER ON THE SIGNAL-BUFFER PRINT.

  THE POWER FEEDERS ON THE EXTENDER CARD ARE NOT HEAVY ENUF.
    +5V ON DATA-PATH CARD EXTENDED WAS ONLY 4.25 V.  MOST OF THIS DROP WAS IN THE +5
  LINE ALTHO THE DROP IN THE GROUND WAS .21V, WHICH IS ALSO EXCESSIVE.  BTW, +5 FROM
  POWER SUPPLY WAS 4.96, AND ON CM-CARD, NOT EXTENDED, IT MEASURED 4.82 .  
  THE POWER SUPPLY SHOULD BE ADJUSTED A BIT HIGHER TO COMPENSATE, BUT BASICALLY ITS OK.

  FOO!  THE POWER SUPPLY GENERATES 5.46V JUST AFTER TURN-ON!! GOES DOWN TO 5V AFTER A
  FEW MINUTES!!  HMM. WELL I DONT KNOW WHATS GOING ON, IT DOESNT SEEM TO DO IT NOW.
  BUT I DID READ 5.46 ON +5 AT ONE POINT...
  
  IT IS VERY EASY TO LOSE WITH EXTENDER CARD DUE TO CONNECTORS NOT SEATED PROPERLY.


  OBSERVED EXTREMELY MARGINAL SIGNAL ON -WE LINE TO M-MEM ON DP-CARD.
LOOKS LIKE A BLOWN MOD.  YEP, MOD 6 TO DP IS A COMPLETE LOSER. FIXED BY
MODS TO DP AND RG.
  WRITE PULSE SIGNAL TO M-MEM NOW LOOKS GOOD.  TIMING, HOWEVER, SEEMS MUCH TOO
EARLY.  WRITE PULSE ACTUALLY BEGINS A FEW NS BEFORE ADDRESS SET UP RUNNING
M-COUNT-LOOP.
  WRITE PULSE ENDS ABOUT 25NS BEFORE UINST-CLOCK, WHICH IS OVERLY CONSERVATIVE.
TRIED SETTING WRITE-PULSE DELAY TO 7, BUT THIS ONLY SEEMED TO MOVE IT ABOUT 5 NS.
  I SEE. PROBLEM IS THERE IS MUCH TOO MUCH SKEW BETWEEN UINST-CLOCK AND SM-CLOCK.
APPARENTLY SM-CLOCK-EARLY HACK NEEDS ADJUSTMENT.

  MARGINAL M-MEM PROBLEMS SEEM TO HAVE BEEN FIXED EVEN THO CLOCK TIMING NEEDS ADJUSTMENT.


12/6 -DEXTER
  LOOKING AT THE PROPOSED MD CLOCK MOD, I THINK WE NEED TO SYNCHRONIZE THE SIGNAL
NUADR.EQ.VMA.WITHIN.BLOCK SO THAT MEMORY.REPLYING.NOW CAN'T GLITCH IN THE SECOND HALF
OF THE SM CYCLE.  WE ALSO NEED -SM.CLOCK, BUT FOR THIS PARTICULAR USE, IT SEEMS
THAT THE SKEW WILL BE NO WORSE THAN IT IS NOW.

SPEAKING OF SKEW, SM.CLOCK AND UINST.CLOCK ARE NOW WITHIN 2 OR 3 NS OF EACH OTHER

THE ALTERNATIVE MOD TO MD, PROPOSED BY RG, GOES AS FOLLOWS:
	1.MD IS NO LONGER SPY WRITABLE, THOUGH WE RETAIN THE ABILITY TO READ THE
MD BUS.
	2.MD IS CLOCKED DIRECTLY BY SM.CLOCK.  THE OUTPUT DRIVER PASSES THE
CONTENTS OF MD BACK AROUND ON THE MD BUS UNLESS MD.HOLD IS DEASSERTED.  THIS ALLOWS
US TO WRITE THE MD WITH THINGS WHICH SET UP AT EITHER SM CLOCK (MEMORY.REPLYING.NOW)
OR THOSE WHICH ARE READY AT UINST.CLOCK (DEST.MD)
	WE USE THE ALREADY EXISTING DEST.MD.AND.NOT.SOURCE.CYCLE, OR THAT WITH
MEMORY.REPLYING.NOW AND PRODUCE -MD.HOLD

	3.WE BUILD A NEW REGISTER ON THE RG BOARD WHICH HOLDS 32 BIT WORDS WRITTEN FROM
THE SPY AND WHICH ARE ACCESSIBLE FROM THE MFO.  WE USE THIS AS THE DIAGNOSTIC DATA SOURCE
RATHER THAN THE MD.  PERHAPS ON THE SECOND PROTOTYPE WE WILL GET TRICKIER, BUT THERE IS
ROOM TO BE HAD ON THE RG BOARD, AND THIS HACK SHOULD BE STRAIGHTFORWARD AND RELIABLE

	4.INCIDENTLY, WE MODIFY THE VMA AS THE MD WAS TO HAVE BEEN DONE IN THE FIRST
PLAN. IT IS THEREFORE STILL NECCESSARY TO GENERATE -MI.UINST.CLOCK.  

12/6  RG
   PUT IN MOD SUGGESTED BY DEXTER TO SPY-REGISTER (ON RG BOARD).  STILL DOESNT WORK THO.
LOOKS LIKE REGISTER DOES NOT GET WRITTEN PROPERLY.  ONCE WRITTEN, MAYBE IT CAN BE
READ.  (OR, AT LEAST IN ONE TRIAL, (READ-SPY-REG) AND DATA FROM FUNCTIONAL SOURCE 5 WERE
THE SAME...  LEAVING THIS FOR NOW.

   WRONG SENSE OF M.SOURCE.ADDRESS.3 USED IN SOURCE DECODE ON DP BOARD.
EASIEST FIX IS MOVE THE .3 BIT TO AN +ENABLE OF THE '538.  A POSITIVE ENABLE
CAN BE OBTAINNED BY USING THE OTHER SENSE OF DP.M.SOURCE.CYCLE, WHICH IS AVAILABLE.


   COUNT-PP LOOP NOW WORKS.  SUSPECT SPY MOD MAY HAVE MESSED UP (READ-MFO) THO,
OR MAYBE IT NEVER REALLY WORKED FOR REAL ANYWAY.  WHEN STEPPING COUNT-PP LOOP,
IT SOMETIMES DISPLAYS THE WRONG VALUE ON MFO DURING THE EXECUTE CYCLE OF THE INCM.
THE RIGHT THING GETS TO THE PP HOWEVER.  MYSTERY IS THAT IF YOU WAIT A WHILE, HIT
BREAK, AND DO (READ-MFO), YOU GET THE RIGHT THING!  SO MAYBE MFO IS FLOATING OR SOMETHING..
--THIS SEEMS TO BE ALRIGHT NOW.  MAYBE IT WAS THE BENT PIN FOUND BELOW..

   MFO LINES OBSERVED LOOKING SUPER CRUFTY.  FROBBED AROUND.  SEEMS THAT A LOOSE
WIRE ON THE RG-BOARD MAY HAVE CAUGHT AS BOARD WAS PUSHED IN, SHORTING TWO PINS.
TRIED TO TACK DOWN WIRES ON RG-BOARD, THIS SHOULD BE DONE BETTER.

NOW MFO BIT 0 LINE LOOKS OK, BUT IT DOESNT SEEM TO COUNT PROPERLY AT HIGH SPEED.
IF YOU STOP IT, YOU USUALLY SEE 3XXXXXX.  SCOPING MFO BITS 17,18,19.

  MFO LINES LOOK WORSE THAN THEY MIGHT BECAUSE THEY ARE TRISTATE DURING THE SOURCE
CYCLE IF SOURCE IS M-MEMORY OR PDL BUFFER.  THE ZERO GENERATING PROM ON RG SHOULD
BE SET UP TO AVOID THIS (IE DRIVE MFO.BUS ON THOSE M-SOURCE ADDRESSES.).  THIS MOSTLY
JUST INVOLVES WRITING THE PROM CORRECTLY,  HOWEVER, CURRENTLY IT DOESNT HAVE A
BUFFER TO DRIVE MFO BITS 7-0.  I HAVE SKETCHED THIS MOD ON THE DP-AS-SENT-OUT PRINT.

  I ALSO SKETCHED A MOD ON THE DP-PRINTS FOR THE NEXT VERSION OF THE MACHINE.
THIS INVOLVES DRIVING THE MFO LINES WITH A FULL BUFFER AND MOVING A FEW OUTPUT
ONLY LOADS (THE L REGISTER, THE PP, AND THE PI), DIRECTLY ON THE MFO.  WE
SHOULD THINK ABOUT WHETHER WE REALLY WANT THIS.

USEFUL JOB: --DONE
  BRING SPARE BIT OF IREG (E30-(9) ON CM) OUT FOR CONVIENENT SCOPE TRIGGERING.  SET THIS SPARE
BIT IN THE LAST INSTRUCTION OF ALL THE UINST-XXX LOOPS.

MARGINAL COUNTING PROBABLY CAUSED BY WRITE-PULSE TIMING NOT RIGHT.
ADDRESS INPUT TO M-MEM CHIPS DEFINITELY CHANGING WITH WE AND CS BOTH LOW.
FOLLOWING CLOCKS NEED TO BE BROUGHT OUT CONVENIENTLY:
   NUBUS.CLOCK
   TREF  	      (NUBUS.CLOCK DELAYED JUST LESS THAN ON TICK)
   SM.CLOCK.EARLY	ADJUST SO UINST.CLOCK SYNCRONOUS WITH SM.CLOCK.
   SM.CLOCK	      SAME SPEED AS NUBUS.CLOCK (SLOW MODE) OR TWICE AS FAST (FAST MODE)
		       RISING EDGE SYNCRONOUS WITH NUBUS.SAMPLETIME
   UINST.CLOCK        RISING EDGE SYNCRONOUS WITH SM.CLOCK.  ADJUST SM.CLOCK.EARLY TO MAKE
			THIS HAPPEN.
   WRITE.PULSE L      SAME SPEED AS SM.CLOCK, SHOULD PULSE LOW 50 NS THRU 90 NS AT SLOW SPEED.

  ALSO WE NEED TO LOOK AT DELAYS CAUSED BY BUFFERING.  SOME OF THESE MAY POSSIBLY
NEED VERSIONS WHICH ARE EARLIER THAN NOMINAL TO COMPENSATE.

12/7 RG

	FOUND LACK OF POWER WIRE ON CHIP RECENTLY INSTALLED AT E16.  VARIOUS THINGS
  WORK BETTER NOW.

        INCLUDING SPY-REG!!  (MOST OF THE TIME ANYWAY.  BIT 18 WAS OBSERVED TO FAIL ONCE
  WRITING A -1.)   BIT 18 OBSERVED TO LOSE AGAIN. ANOTHER TIME, THE WHOLE LEFT HALF
(16 BITS) WROTE ONES WHEN IT SHOULD HAVE BEEN ZEROS.  ANOTHER TIME, BIT 18 WAS DROPPED
ON A WRITE TO IREG.

	STILL IS .1V DROP IN GROUND AND .2V DROP IN VCC OF EXTENDER CARD.

	found error in MD mod.  MD count loop works.  unfortunately, there is a 
	 noise problem about bit 18.  if you hang the scope on MD18 d8(6) while
        it is running, you see various glitches instead of nice counter action.
	not clear if this has any relation to bit 18 problems noticed above, it
	might..

     traced mfo.18 problems to losing backplane.  grossly losing backplane.
  all manner of shorts, high resistance connections, opens, etc etc.

12/9 dexter traced more bugs in the spy.reg logic , it all works now.

12/12 RG
	ADDED SLOW MODE TO INIT-TRAM, WHERE IT ALLOWS TWO TICKS FOR EXECUTE CYCLE.
   THIS MAKES M-COUNT-LOOP AND A-COUNT-LOOP WIN.  DO (INIT-TRAM NIL T)
   AFTER NORMAL INITIALIZATION TO CAUSE THIS TO BE LOADED.

   LOTS OF THINGS NEED TO BE DONE TO FLUSH NOISE FROM POWER AND GROUND:
	IMPROVE WIRING TO ALU'S
	ADD CAPACATORS, VARIOUSLY, ESPECIALLY LARGE ONES (EITHER 22UP DIP CAPS
	  OR TUBULARS).  ALSO ADD ORANGE TATALUMS NEAR POWER SUPPLY FEEDS.
        CONNECT PRIVATE BUS BACKPLANES TO SYSTEM GROUND

   TRIED OUT VMA.  MOSTLY SEEMS TO WORK. HOWEVER, IN SINGLE STEP MODE, IT SOMETIMES
   GETS A FALSE CLOCK.  THAT IS, IF YOU PUT IT IN VMA-COUNT-LOOP AND SINGLE-TICK,
   THE VMA CHANGES WHEN IT SHOULD, AND ALSO AT ANOTHER TIME, DURING THE EXECUTE CYCLE
   OF THE 0 UINST WHICH CLOSES THE LOOP.  DONT KNOW IF THIS DUE TO SOME SORT OF NOISE
   PROBLEM OR CLOCK SKEW OR WHAT...

12/12 RG SECOND SESSION.
   FOUND OUT VMA PROBLEMS DUE TO PULSE ON LC.to.VMA.enable.  checking mod.

   found vma false triggering due to spurious pulse on uinst.macro.stream.advance
       comming across backplane j2-88.  could not find any stray paths with 
       ohmmeter.   temporarily grounded lc.to.vma.enable F31-13(16) with white wire.

   SPY REG SOMETIMES CHANGING AS MACHINE WAS CLOCKED (NOT AFFECTING SPY REG).
   PROBLEM DUE TO POOR DRESS ON CLOCK WIRE FROM E15-10 TO SPY REGISTER.
   REPLACED WITH TWISTED PAIR.

   STILL A NOISE PROBLEM WITH LOADING VMA.  TRY (VMA-TEST-LOOP 40).  USING LOGIC
   ANALYZER, IT SEEMED PROBLEM HAD TO DO WITH SOURCE CYCLE.  IE, WHEN IT LOST,
   WRONG DATA WAS AT FF INPUT FOR QUITE A LONG WHILE BEFORE CLOCK.
   LOOKING AT POWER ON DP BOARD WHILE RUNNING (VMA-TEST-LOOP 40), THERE WERE 
   3/4 VOLT NOISE PULSES.  SO, POWER-GROUND FIXUPS SHOULD BE DONE BEFORE
   TRYING TO TRACK THIS DOWN FURTHER. WILL PUT ERROR CHECK IN WRITE-VMA ROUTINE FOR NOW.


   FOUND DIRECTION INPUT TO BI-DIR BUFFERS IN MAPS IS INVERTED.  OTHER POLARITY
   OF SIGNAL IS AVAILABLE, FORTUNATELY.  MODS MUST BE FIGURED OUT AND WRITTEN UP.

   HIGHEST PRIORITY IS TO FIX UP POWER AND GROUNDS.  (I DIDNT GET A CHANCE TO LOOK AT MASKER).

12/14 RG
   DOREEN PUT DIRECT JUMPERS FOR POWER AND GROUND ON ALU'S.  DID NOT HAVE A CHANCE
    TO INSTALL WIREWRAP GRIDS AS WELL.  JUMPERS ALONE SEEM SOMEWHAT BETTER THAN BEFORE,
    BUT STILL NONE TOO GOOD.

   EXPERIENCED FLAKEY OPERATION OF M-LATCH, PARTICULARILY HIGH BITS.  EXPECT THIS IS
   PARTLY DUE TO GROUNDING PROBLEMS ABOVE, AND PARTLY TO KNOWN MARGINALITY THAT
   T.SOURCE.CYCLE, WHICH CAUSES LATCHES TO LATCH, IS ALSO WHAT CAUSES INPUT TO THEM
   TO GO AWAY.  THIS OKAY AS LONG AS THERE ISNT TOO MUCH NOISE, SINCE PROPAGATION DELAY
   FOR DATA TO GO AWAY IS LONGER THAN FOR LATCH TO LATCH.  BUT WITH NOISE,
   VARIOUS INSTANCES OF T.SOURCE.CYCLE MAY APPEAR TO BE SLIGHTLY SKEWWED WITH RESPECT
   TO EACH OTHER.  SUGGEST FIX IS TO LATCH M-LATCH WITH VERSION OF T.SOURCE.CYCLE L
   DIRECTLY FROM BACKPLANE. (**UNFORTUNATELY, BACKPLANE SIGNAL IS WRONG POLARITY FOR
   THIS***)
   THIS VERSION WILL BE EARLIER BY A BUFFER DELAY AND THUS
   SUPPLY POSITIVE TIMING.  IN THE OTHER PHASE, THIS WILL CAUSE M-LATCH TO UNLATCH
   A TAD EARLY, BUT DO HURT BAD DATA WOULD HAVE TO PROPAGATE THRU ALU, OUTPUT SELECTOR, ETC.
   YOU COULD MAKE A SLIGHTLY STRETCHED VERSION OF T.SOURCE.CYCLE WHICH HAD GREATER DUTY
   IN THE LOW (HOLD) PHASE AT BOTH ENDS.  PROBLEM IS IF YOU USE AN OR-GATE TO MAKE
   THIS YOU ARE JUST DEPENDING ON OR-GATE TO BE FASTER THAN A BUFFER TO AVOID THE
   PRESENT PROBLEM.

   --LETS TRY THIS ONE...--
   AHH, HERE'S AN IDEA.  AN AND-GATE HAS BEEN ADDED TO T.SOURCE.CYCLE
   ON THE RG BOARD TO ENABLE GATING IT OFF DURING SPY CYCLES.  THERE IS NO NEED FOR
   THE M-LATCH L SIGNAL TO BE SO GATED OFF.  SO WE CAN INSTALL A LOW-STRETCHING
   GATE IN PARALLEL WITH THAT ONE TO PRODUCE A NEW M.LATCH L SIGNAL, WHICH WE RUN
   OVER A NEW BACKPLANE WIRE.


   HACKED INIT-TRAM TO HAVE SEPARATE OPTIONS FOR DOUBLING EXECUTE CYCLES AND
   SOURCE CYCLES.  UNFORTUNATELY, FOR THE TIME BEING, BOTH ARE T BY DEFAULT SINCE
   THATS WHAT IT TAKES TO MAKE MACHINE WORK.

   WHILE POKING AROUND ON ALU'S, NOTICED A GROSS NOISE PULSE ON F18-(4), WHICH IS
   FUNCTION INPUT TO ALU, OCCURING AT TRANSITION FROM SOURCE CYCLE TO EXECUTE CYCLE.
   THESE LINES ARE SUPPOSED TO BE CONSTANT ONCE UINST HAS COME UP.  INVESTIGATING THIS,
   I FOUND GROSS NOISE BEING INTRODUCED IN THE IREG BITS COMMING FROM THE BACKPLANE
   BY THE COUPLING FROM THE MFO.BUS TRANSITIONS.  ALSO, THE FACT IT HAS TO COME
   ALL THE WAY ACROSS THE BOARD TO THE ALU DRIVERS, LOCATED IN THIS CASE AT L24 AND
   L25 DOESNT HELP. HMM.  ON THE NEXT MACHINE, WE SHOULD PROBABLY SWAP THINGS AROUND
   ON THE CONNECTORS SO THE SM CLOCK RELATED STUFF IS ON ONE CONNECTOR AND THE
   UINST CLOCK RELATED STUFF IS ON THE OTHER.  IN THIS CASE, THAT MEANS SWAPPING THE
   A.SOURCE.AM.WRITE LINES, WHICH CAN CHANGE EVERY SM CLOCK, WITH THE MAIN.UINST LINES,
   WHICH HOLD OVER A UINST.  ALSO, WE SHOULD DISECT THAT BURNED OUT BACKPLANE BUS
   STRIP TO SEE IF THERE IS A GROUND ISOLATING TRACE BETWEEN THE SIGNAL TRACES.
   GROUNDING OR TERMINATING THE BUS STRIPS MIGHT HELP TOO.  THIS NOISE PROBABLY HAS
   ABOUT AS MUCH TO DO WITH VARIOUS LOSSAGES AS THE ALU POWER-GROUND PROBLEM.

   FIXED EXTRANEOUS WIRE IN UINST.WRITE.L1.MAP ECO. THE ERROR MAY HAVE BEEN CAUSED
   BY A TYPO IN THE RUN NAME IN THE ECO AS WRITTEN UP, ALTHO THE ACTUAL WIRES WERE RIGHT.

   NOW THE PROBLEM WITH WRITING THE LEVEL 1 MAP IS THAT THE INPUT TO THE DESTINATION
   PROM IS WRONG. IT IS T.NEW.UINST, WHICH CAUSES THE PROM TO SET UP AND STROBE
   THE LATCH AT THE SAME TIME AS UINST-CLOCK.  IT NEEDS TO BE T.CLOCK.BEFORE.NEW.UINST,
   SO THE WRITE PULSE GETS GENERATED ON THE LAST TICK OF THIS UINST.  I GUESS WE'LL
   HAVE TO GOBBLE DOWN A SPARE TRAM BIT FOR THIS.  I THINK THIS IS THE ONLY PLACE
   T.NEW.UINST IS USED NOT ON THE RG BOARD, SO I THINK THE BACKPLANE WIRE CAN BE RECYCLED.
   (BTW, MAP WRITING WILL HAVE TO BE A "slow destination" BECAUSE THE WRITE OCCURS
   DURING THE CURRENT UINST, NOT DURING THE EXECUTE OF THE FOLLOWING ONE, ETC.
   SO THE UINST.SLOW.DESTINATION BIT MUST BE SET IN ALL MAP WRITES, AND THE TIMING
   RAM LOAD HACKED TO TAKE THE NECESSARY EXTRA CYCLE.)

12/15  FIXED SEVERAL ERRORS IN ECO'S.  MACHINE NOW WORKS AGAIN AFTER M-LATCH CHANGE,
  BUT IT DOESNT FIX VMA PROBLEM.  LOOKING AT IT FURTHER, IT LOOKS LIKE
  THERE'S GLITCHES ON VMA-CLOCK WHEN IT LOSES.  HAVENT QUITE TRACED SOURCE OF THOSE.


12/16  VMA CLOCK SCHEME IS A LOSER.  GLITCH MAKER INSTALLED TEMPORARILY, NEXT MACHINE
  SHOULD USE SEPARATE 2 INPUT SELECTOR AND ENABLED REGISTER.  VMA WORKS!!!

  NOW TO INSTALL T.SLOW.DEST.WRITE SO WRITES TO MAPs win.
  CURRENT BACKPLANE WIRE T.NEW.UINST IS USED ONLY FOR THIS, SO IT IS REDEFINED TO BE
  T.SLOW.DEST.WRITE

  YEAH!  LEVEL 1 MAP WORKS.  HAVENT TRIED EITHER LEVEL 2 YET.
  ADDED LEVEL 1 MAP TO LAM-TEST-MACHINE.
  HACKED FAST-ADDRESS-TEST-LEVEL-1-MAP, IT WINS!


12/18  HAD NOISE PROBLEMS ON HIGH ALU BITS..

  ADDED (RESET) FUNCTION.  DO THIS IF YOU QUIT OUT OF A LOOP AND THINGS SEEM
   MONSTOUSLY BROKEN.  WHAT CAN HAPPEN IS THAT IT LEAVES BITS IN THE CONTROL
   REGISTER WHICH SCREW YOU, LIKE SPY.CONTROL.TRAM.
  REMOVED WHITE WIRES ON CM BOARD DISABLING IMOD AND IREG 12,13.
   IREG 12, 13 CAUSED STRANGE LOSSAGE WHEN NOT GROUNDED OUT, SO REINSTALLED WHITE WIRES.

  SOMETIMES SPY REG WONT LOAD RELIABLY.

12/19  BY THE WAY, THE MASKER IS NOW 32 BITS.  SIMPLE READ BACK FUNCTION GIVES
       THE RIGHT DATA IN PROM, ASSUMED TO WORK (ACTUALLY DID THIS ON THE 17TH)

	the spy reg loads ok after doing noop uinst clocks.  when wedged, seems to
be writing good data, but reading bad.  waveforms on read indicate fighting on mfo bus,
but source cycle is suppressed, so drive is coming from somewhere else. after  exiting
the wedged state on one trial, there were some high bits set in the spy reg,but they
weren't stuck and they were not the same as the bits failing on readback.  instead
of doing noop clocks, we can now try to unwedge by zeroing the ireg directly, half
at a time.   .... aha, its some bits in the low half of the ireg...btw reset does not
force uinst clock low..had problems writeing ireg because it was high. ....ok,the problem
is the mf bits, looks like they are not tied to zero  -   yep, the mod was in on the dp
board instead of cm.
	this problem demonstrates the need to suppress the drive of the q reg when not
wanted and to suppress other mfo sources when we do need to write the cram.

	now working on the jump tests...eratic failures, but everything works more than
not.   looks like a noise problem or perhaps a floating input.  tends to fail for cases
where m source  is equal to a source (both for jump failure, and for  spurious
jumps)    
	theres a reasonable amount of noise on the dp.uinst.clock.a testpoint,
particularly at the source.cycle/Execute.cycle transition.  it may be that theres
problems with the jumper for the test point.  on cm, where we would like to find some
noise to mess up the clock,cm.uinst.clock.a looks just fine

12/24 RG
  THE GROUNDS ON THE J2 AND J3 CONNECTORS SHOULD BE WIREWRAPPED BY TWO SHORT DIRECT
WIRES TO NEARBY PIN 10'S.  USE THE HEAVIER HAND WIREWRAP WIRE INSTEAD OF THE 30 GAUGE
PRECUT STUFF...  SEVERAL WERE HOOKED BY ONLY ONE LONGISH ROUND-ABOUT WIRE.  THE
GROUNDING IS INADEQUATE ANYWAY, BUT WE MAY AS WELL WIN AS BEST WE CAN.

 12/31
still having problems with md.. it gets into states where it won't load, apparently
because it is getting a bogus memory reply or something.

a-mem is now wedged.  m-mem works fine, and if you write a and read m, you get
good data.  wonder if it had anything to do with the new dmask prom? ...seems to -
things work with the old unburned prom...didn't hit md problems this time around

1/1
A MEM WORKS, T.CONTROL.A.ADDRESS WAS WRONG POLARITY,RG CHANGED SOFTWARE

SM.CLOCK RUN HAD BEEN BROKEN BY MI-MOD #15.  FIXED.  CSM-REG-VIA-CSMRAM NOW WORKS.

TREG LOSSAGE OBSERVED RECENTLY (BITS 20 AND 21 SHORTED) WAS DUE TO BENT PINS
ON PRIVATE BACKPANEL.  OK NOW.  WATCH THOSE PINS.

ENCOUNTERING DIFFICULITES WITH MD OF THE KIND WHERE THE 8 HIGH BITS DONT LOAD
PROPERLY ALTHO THE LOW 24 DO.  THIS STARTED HAPPENING AFTER THE SM.CLOCK
RUN ON THE MI BOARD WAS FIXED.  THERE IS A BASIC MARGINALITY HERE, BETWEEN SM.CLOCK
AND UINST.CLOCK.  WE REALLY
NEED A SM.CLOCK.EARLY SIGNAL TO CLOCK THE MD TO MAKE SURE IT GETS CLOCKED BEFORE
THE DATA GOES AWAY.  (NOTE THAT THERE IS NO DANGER IN CLOCKING THE MD TOO EARLY
SINCE IF THE MD IS GOING TO LOAD WITH SOMETHING DIFFERENT THAT IT ALREADY HAS,
IT IS NOT DRIVING ANYWHERE.  ANOTHER WAY TO LOOK AT IT IS THAT THERE IS A SINGLE
BIDIRECTIONAL PATH OVER WHICH THE MD IS LOADED AND READ, SO IT CANT SUFFER A
SKEW PROBLEM IN THE WRITING DIRECTION.)  THIS SM.CLOCK.EARLY SHOULD PROBABLY
BE GENERATED BY TAPPING DIRECTLY OFF THE DELAY LINE BEFORE THE BUFFER THAT
GENERATES SM.CLOCK, ALTHO IT MIGHT LIKE TO BE EVEN A LITTLE EARLIER THAN THAT.
AS I REMEMBER, THAT DELAY LINE IS CURRENTLY SET UP FOR ZERO DELAY, THO.)

1/2  RG
WRONG SENSE OF LAMBDA.DMASTER USED TO PRODUCE LAMBDA.DMASTER.SYNCED.  DOES
NOT TAKE ACCOUNT OF FACT ITS AN INVERTING REGISTER.  INSTALLED MI MODE TO FIX IT.
MD WORKS MUCH BETTER NOW!  **THERE IS ALSO A BUG THAT MEMORY.REPLYING.NOW
COMES TRUE ON EITHER A READ OR WRITE.  AS OF NOW, THAT FROBS THE MD.
EITHER MEM.REPLYING.NOW SHOULD NOT HAPPEN ON WRITE CYCLES, OR THE MD SHOULD NOT
GET FROBBED EXCEPT ON WRITES.
SCRIBBLED MOD DIVIDING MEMORY.REPLYING.NOW AND MEMORY.REPLYING.NOW.ON.READ.
DIVISION IS SCRIBBLED ON MEMORY.REPLYING.NOW SIGNAL RUN IN MOBY BOOK.

NOTED THE SENSE OF = IN THE JUMP MICROINSTRUCTION HAD BEEN INVERTED. ANY CHANGE TO
MICROCODE MUST BE DOCUMENTED AND DISCUSED!!  IN THIS CASE, I GUESS ITS OK.
DO THE <= CONDITIONS NEED TO BE INVERTED TOO?

1/3
WE DISCUSSED THE CHANGE IN THE UCODE FOR THE JUMP LOGIC WHEN I DESIGNED THAT PART.
WE TALKED ABOUT IT AGAIN A WEEK OR TWO AGO WHEN THE JUMP TESTS WERE BEING WRITTEN. 
NO, THE OTHER CONDITIONS DO NOT NEED TO BE INVERTED EXCEPT FOR PAGE FAULT. -DEXTER

1/15 just checked the pi,pp,and pdl ...just get ones back
     
     some other problems:
	stat counter won't increment, bit zero stuck high
	hram can't be read back, get value of pc instead
	read and write of stack and stack pointer still having problems

	single step logic needs to be modified to turn off uinst halt if
	the instruction is nooped.  (that seems more useful to me; for example,
	when writing the cram, a spurious halt could stop the machine when
	the ireg was loaded with the half-finished data in the cram, when actually,
	we had set noop to avoid executing the random data.)

	a related bug is that parity checking on the ireg must be turned off when
	when randomness is loaded into the ir during a write of the cram



added the field specs to the debug uinst file for halt, macro-stream-advance,
md-to-macro-ir, and macro-ir-dispatch.  

*****It turns out that we never generate uinst.other.halfword, so this is left floating.
	if we use the spare bit in the uinst, we must delete it when used in diagnostic
	loops; or at least call it by name; it may not do any harm to leave it in.
	$$$ PROBABLY SHOULD JUST PUSH PIN IT LOW FOR THE MOMENT

1/16 RG

   WRITE CYCLES WORK, BUT 4 BIT OF MD IS DROPPED ON WRITE.
   TRACKED DOWN BROKEN WIRE.. FIXED.

1/17 RG
   MAIN MEM COUNT LOOP FAILS TO COUNT FOR SOME REASON EVEN THO IT
   SITS IN LOOP, READING AND WRITING.  BACKPLANE NOISE?
   KNOWN THINGS THAT NEED TO BE ATTENDED TO:
     HOLD IF MEM CYCLE IN PROGRESS ON WRITES TO VMA, MD.
     MORE ROBUSTNESS IN CSM, AVOIDING STATE WHERE CSM THINKS MEMORY
       CYCLE FINISHED WHILE FF'S STILL SET.

1/29  tracing main mem count loop problem.  MD count loop fails now too.
   reason is, something is fighting MD on source cycle, causing it to read 0.
   problem is, zero generating prom generates 0's for source MD as opposed
   to MD-NO-HOLD.!!

1/29	we have some problem such that the wd memory board needs two memory inits
	before it responds properly -dexter

2/3  RG
   Traced various problems.  One of the simpler one seems to be that the
534 in D5 refuses to work.  have replaced chip twice.  its getting clock,
yet, input at pin 13 (mi.nubus.ack L)  is high at relavant time, yet output
at pin 12 is solidly hi.  something random going on with the socket or something.

   some lossage may be due to noise on special.memory.clock, check this.

   there is a bug which can cause CSM to trigger twice on same memory cycle.
was observed to happen on logic analyzer.  If T.hold is on, nothing in loop is
affected by UINST.clock so it can happen more than once.  (however, in normal
single stepping, T.HOLD is not usually on (halt.request is), so this does not
happen as often as we were thinking at one point.)

   single stepping memory-count-loop, it reproducably hangs on the second time around
due to nuadr.eq.vma.within.block not being true.  (The address is supposed to
go from the address drivers to the decoders and always be equal if its not a block operation).
This causes us not to get memory.replying.now, and things hang.  Conceivably, logic
could be made more robust by using the 2nd section of the memory.replying.now AOI
to hack on (NU.xfer.last.cycle) AND NOT (block.op), but it should work the way it is now...


2/7 Dexter ... working on prints:
	NU-DEBUG   wirelisted ok..quick double check and then send it out

	CM	finished first pass, including redo of the pc control
		except for the no-op logic.  that needs redesign, including
		some thought on its desired behavior.  Created new print
		"jump-control" and trashed pc-control-II, though it was kept
		around for reference...restoring the old state of the prints
		might have problems if it disappears.

	RG	this is the next project: much is already entered, thanks to youcef

	DP	here we have only a few mods, but its crucial to fix the q reg
		before anything new is added


	MI	this has the cache logic to be investigated, and may need some
		rework on memory logic, so save for last.

	*****we need to start the work on the parity logic in the next few days.
	I plan to shift from the prints to the interrupt logic on late wednesday
	or thursday.

2/7 DEXTER
	JUST NOTICED THAT THE HRAM IS ENABLED EVEN WHEN WE ARE JUST SM STEPPING
	THE MACHINE, SO I WOULD RECOMEND TIEING THE NORMAL RUN MODE TO ENABLE LAMBDA.

2/8 RG+NGL postscript
	revamped memory control logic, flushing special.memory.clock and generally
	causing more winnage.

2/8 RG  correct address not getting to nubus when single stepping due to latch
	on L1 map output which holds unless source cycle.  This latch was an attempt
	to be conservative, but it really serves more like a buffer.  

      memory cycles now work when single stepped!  however, MD gets clobbered 
      in single uinst mode.  this happens even in MD-count-loop.
2/10 Rg+NGL
	md clobbering happening on spy cycle with md -> md.bus transceivers enabled.
	fixed by extra term on enabling gate.  Memory references now single step
	correctly.

     RG  investigating problem that CSM sometimes goes to error stop when
	NUDEBUG takes cycle while Lambda is running.  Found that its possible
	for CSM to think memory cycle should have started (ie it sees Lambda.dmaster
	high) when actually, it hasnt. (ie you lost the NUBUS just then, and
	between delay in syncroniser and drivetime vs sampletime).
	added a bunch of PAL outputs to CSM input state testor and changed software.
	unfortunately, I seem to have broken it.. Software losing somehow, will
	look at it tomorrow.

2/11 RG
	previous breakage was caused by CSM not initializing properly after it was
	started at 0, since a random dispatch block was stored in 0.  Changed
	CSM assembler to not use block 0 and store a copy of IDLE-TEST there. that
	fixed that.

	now its back to winning pretty much.  however, if LAMBDA is running and
	you do a (mrw 0), there is a fairly low probability that it will cause the
	CSM to think it has gotten a TIME-OUT response to an attempted WRITE.
	modified CSM code so it sets CSM.VERIFY.CYCLE in the timeout loop error
	for ease of triggering logic analyzer.  Looking on NUBUS, there really is
	a glitchy TM1 then, which it is within its rights to interpret as a timeout.
	This occurs on the first cycle after the NUDEBUG has become master and
	taken its cycle.
	 This looks like a bus-converter problem.  Namely, SSTM1 on the bus converter
	comes from this 2-input selector which  is controlled by GBUSY.  GBUSY is
	changing just about the time of the glitch.  There are some mods penciled
	in to bus converter diagrams which should be checked over.
	(note that the 2-input selector is drawn sort of with the wrong pinout.
	The output at pin 4 comes from either pin 2 or pin 3 in a S257).
	  Tomorrow will add more test points to bus-converter
        and attempt to trace this down.

2/25/83
  observed "consecutive write" problem which seems to be due to faulty write-pulse
	timing for A and M memories (at least).  Problem is, -write goes low at
        beginning of minor cycle (driven directly from T.RAM) and -CS goes high
        a little later, generating a false write.  (-CS later pulses low for the
	real write pulse.)  Fix is to generate a new backplane signal, -WRITE.ENABLE,
	which would be IOR'ed with various -WRITE lines.  Ideally, this would
	pulse low a few nanoseconds (5-10) after the beginning of the minor cycle
	and remain low until a few nanoseconds before the end of the minor cycle.  (The
	behavor near the beginning of the minor cycle is much more critical..).
	For now, I propose to generate this via a S51 circuit identical to that used
	to generate -write.pulse, with the leading input comming earlier than that
	for -write.pulse.

	backplane wire to use:  recycle T.uinst.clock.to.MI, J3-B7(39).

	decided to put it in simpler for the time being.. use unbuffered version of
	-write.pulse for -write.enable.  This only requires mods to DP board.

	well, sure enough, that didnt work too well.  There was observable (but
	not gross) fighting, and the -write.pulse going away tended to shorten the
	write interval a bit too much.  So revert to the previous plan..

	now in "right".  sources no longer get clobbered, but destinations
	still gets written wrong on consecutive writes running at full (ie half)
	speed.

note!!  5 tap TTL delay line dip definition is still WRONG!!!!

2/26/82
	investigating consecutive write problem noted above.  Found gross noise
	on VCC and ground near output bus selector chips.

	decided to change A and M "latches" to "registers".  ie replace F373's
	with F374's, which, fortunately, are pin compatible.  Idea is to stop
	garbage data from being input to ALU during source cycles.  This garbage
	comes out as real nasty garbage, which then gets dumped into the output
	selector, and seems to be causing above noted noise.
	This really makes good sense anyway since the source cycle is the limiting
	timing of the machine there was nothing being gained by the "flow through"
	aspect of latches.  Will require a change in TRAM software since rising
	edge will trigger latches.  Also, some kludgery put in between tram bits
	themselves and the backplane wires will have to be flushed.  No actual 
	wire changes on DP board, except for the fact I think I will flush the
	buffer put in the M side in a previous mod.

	Hmm.  T.latch.M.operand was comming from random logic, not a separate TRAM
	bit.  I guess we can still play the same game by hooking T.M.clock to
	T.data.paths.to.MFO.  (it would make a little more logical sense to hook
	it to -T.source.cycle, but unfortuately the polarity is wrong and the
	delay of an inverter would be undesireable.)

	change to registers wins, noise greatly reduced. fast-load-straight-map
	runs at full (ie half) speed without no-ops, consecutive write test wins, etc.

  session II

	tried running MEMD.  found USP decrements pushj from dispatch. control
	transfers to right place.

	found selector inputs swapped on 4 input selector that generate
	jump, return, conditional-pop, conditional-push.

	This happens a super lot.  All selector inputs should go from most significant
	to least significant from top of page to bottom of page!!!
NGL+RG
	PROM which translates dispatch.P and dispatch.R to JUMP, return, conditional.push L,
	conditional.pop L was screwwed up.  Modded.  Dispatch.P pushes and Dispatch.R
	pops now.

	overhauled micro-stack functions, fixed various software bugs.

	function destination micro-stack-data is really doing micro-stack-data-push.

	looking over destination logic, it doesnt have a chance to work.  ie there
	used to be a COUNT.USP line comming from destination prom, but it seems to
	have been flushed, so there is no way to distinguish micro-stack-data-push
	from micro-stack-data.  Suggest Uinst.dest.USP line be recycled, maybe.
	For now, anyway, the micro-stack-data destination does not exist.

	other problems with us.  dest-micro-stack-push writes both pdl locn pointed
rdm	to currently by usp and also that locn plus one. Fixed by mod CM-ECO#22,
	which ORs into WRITE.US L the signal WRITE.ENABLE L to produce a "write pulse".

	The delayed write-pulse thing on the RAMs seems to have fixed the MID completely.
	Someone should write a fast-address-test for it (but if you do, leave RDM mail
	so he doesn't do it next time he comes in...).

RG	The new CM prints seem to be in an inconsistant state.  What I think happened
	is that us.push and us.pop got "saved" but all references to them were not updated.

	POPJ-AFTER-NEXT doesn't work.. usp decrements, but next pc comes from pc+1, not US.
	gee. its not clear how to fix this winningly without going back to another level
	of AOI, a la CADR....  For now, will flush use of POPJ-AFTER-NEXT.

	stepping the machine thru memory cycles with LAM now hangs, although stepping it
	with SM-STEP-LOOP still wins.  what is undoubtedly happening is that the CSM
	is triggering off with the machine in single-minor-cycle mode and isolated from
	the NUBUS and getting itself in wedged states.  A memory cycle really doesn't have
	a chance to win unless clock is running full steam anyway.  Thus, a clock running
	signal should be available to the CSM and it should not start a cycle
	unless clock.running is asserted.  debug.clock.mode.synced L looks like the right
	signal to bring out on the backpanel and connect to input 1 of selector for 
	CSM.address.2 .  

2/27 RG
	turned out hanging due to assembler bugs not setting slow destination
	for memory destinations, but, previously mentioned CSM mod is a good idea anyway.
	when it is made, the CSM await-command loop must be modified so as to
	loop unless it sees clock is running.

3/2 rdm
	IMOD stuff now "appears" to be working.  However, bits 12 and 13 weren't, as
	they had been previously wired down.  So, I looked around for the wires to them
	to remove them.  Apparently, they were both just wired down to ground in the
	middle of their paths by adding a third wire to one of the posts.  YUCK!
	After they were removed, curious things happened.  If you ZOOM the machine,
	it works, but if you try to write the spy-reg (or maybe other things, I don't
	know) -- it fails.  Sigh.  IF YOU THEN READ THE Q-REG, AND THEN WRITE IT ZERO,
	things like writing the spy-reg seem to win.  Curious.  However, TEST-IMOD-DATA-PATH
	claims that when trying to write bit 13 by its lonesome from the CRAM with a
	zero from the spy-reg going to imod-low, that the IR is zero instead of 20000.
	HOWEVER, it doesn't have the problem writing a zero to the CRAM and bit 13 to
	the spy-reg as imod-low. Curiouser.  And then, I have a routine called
	WRITE-IMOD-LOW-AND-CHECK, which can try writing data to the IMOD both ways.
	(WRITE-IMOD-LOW-AND-CHECK 20000) and (WRITE-IMOD-LOW-AND-CHECK 20000 T) BOTH
	WORK! Curiouser and curiouser. (The program TEST-IMOD-DATA-PATH checks the
	equivelent to WRITE-IMOD-LOW-AND-CHECK N T, then WRITE-IMOD-LOW-AND-CHECK N,
	then WRITE-IMOD-HIGH-AND-CHECK N T, and lastly WRITE-IMOD-HIGH-AND-CHECK N,
	where N steps a single one across from right to left.  So I tried the two
	writes in different orders, just in case it was order dependent, but it
	didn't seem to matter.)
		Therefore I suspect foul play by the 12th and 13th IR bits not being
	tied to zero during critical times.  Your job, should you chose to accept it,
	is to try and save the LAMBDA project from this deadly bug.
		You have till the 31st of April.  Good luck, Jim.



3/3 DEXTER

	POPJ FIX IS IN, BOTH FOR JUMPS AND DISPATCHS.  I POKED AROUND WITH JUMPS,
	TRYING POPJS DURING PUSHJS WITH AND WITHOUT THE N-BIT SET.  DID NOT TRY
	DISPATCHES YET.  DISPATCH MOD IS MUCH SIMPLER, I HOPE I DID IT RIGHT.
	DOCUMENTATION IS STILL IN MY GREEN NOTEBOOK IN THE ROOM WHERE NOBLE AND
	I HAVE BEEN WORKING.  I'LL PUT THE MOD IN THE ECO FILE FIRST THING TOMMORROW,
	BUT HAVE RUN OUT OF STEAM FOR TONIGHT. -DEXTER

3/3 RG
	Dispatch mod seems to work OK.  Didnt try POPJ-AFTER-NEXT.  fixed various
	software glitches, etc.  Current state is that memory tests parts 0-5
	seem to work reliably!.  Part 6 transfers to randomness.  Hacked LAM 
	breakpoints to use LAM-IR-HALT bit, but it doesnt seem to work.  Also,
	there needs to be an easy way installed to test if machine is halted.

3/4 RG+DEXTER
	found lam-ir-halt doesnt work because it asserts halt request after
	source cycle timing ram codeword has already been fetched for UINST in question.
	mod should be worked up whereby LAM-IR-HALT turns off ALLOW-UINST-CLOCKS.


	memory test parts 0-5 seem to work reliably.  Part 6 transfers to randomness.
	Pretty clearly, reason is faultly operation of USP.  If you start it at 0,
	it winds up at 11 even tho there is only one level of subroutine.  I expect
	glitch maker is not making a wide enuf glitch or something.  Rather than
	waste time fooling with the losing '193s, should we bite the bullet and 
	put in a mod to use 163's for the USP as in CADR and next version of LAMBDA?
	I'm afraid maybe so...

3/5 dexter
	a day or so ago, I found that one instance of arith-cond jumps with particular
	data seemed to fail.  Ron and I will look at it on monday or so
3/6 dexter...no problem, fixed when we replaced F181s with S181s

	I added the mod to inhibit uinst clocks when ir-halt is on


**********************************************************************************************
	Here are the tasks between us and a second wirelist:

	1.finish redesign of pc/stack logic

		a. make usp loadable again?
		b. widen jump conditions to 16?
		c.

	2.get prototype's stack working, generally get machine to show more signs
	  of life.  WHAT WOULD BE A GOOD CRITERION FOR "WORKING ENOUGH TO SEND
	  OUT THE WIRELIST"??

		a. note that getting stack working may involve ripping out 193s and
		   replacing with 169s ...big mod, no pin compatibility

	3.review backplane wires. I know we need one for a=m.datatype. What others
	  are outstanding?

		a. a=m.datatype
		b. debug.clock.mode    (see note 9 below)

	4.put datatype compare in the prints  -done, except for backplane, by ngl --rg

	5.placement of boards: dp has had only a little decay...rg in intermediate shape
	  cm and mi hardly touched

	6.add a debug port to the lambda.  idea is to keep it as simple as possible...
	  acts something like a slow nubus?  (if we have to, this could be flushed)

	7.finish moving internal mode register to the RG board, make it a source on the
	  spy bus (mfo might be better, but we've got enough chips on that one)
	  ....or maybe read it back with the con reg.

	8.expand con reg anyway, read as much state info from the machine as possible

	9.mod so that csm can sense whether sm.clock is ticking
	  --another backplane wire!!

	10.is the multiplier all done???

	11.fix mods to q-register drive and read parity so that we can write cram
	   at run time and checkout the parity logic
           --actually flush mods to Q register and install new hack involving setting
	   noop on write of destination CRAM-HIGH or LOW. (new destinations.)
	   Put in mod so IR.HALT will not halt machine if NOOPed, and make sure all
	   other IR bits do nothing if nooped.

	12. finish mod so instructions which clobber mem subroutine dont need slow.destination
	   set.  This involves flushing T.hold.control.0, renaming memory.cycle.in.progress
	   backpanel wire hold.for.memory, and adding logic on the MI board to drive it.
	   hold.for.memory = memory.cycle.in.progress AND 
				(Uinst.clobbers.mem.subr OR LC.to.VMA.enable).
	   Uinst.clobbers.mem.subr =
			(dest VMA OR MD OR MAPs) which should come from destination PROM.
	   figure out exactly how to do this with minimum backplane wires....

***	13. mod destination prom to assert uinst.write.a when.asserting uinst.write.m
	    (this will cause the passaround logic to work properly for write m-foo
	     followed by read a-foo)
	    -or do something more interesting on WW2 to conserve backplane wires??

	14. MOD cm board to change US-TOP-LEVEL-FLAG to US.18 from US.16 .  This is not
	   too high priority.

	15. add ways to read in misc. data.  including 25.bit mode, high.pdl.address.bit
	    lc.to.vma.enable, interrupt.enable, sequence.break.enable, etc.
	    macro.instruction.byte.mode
rg 3/6/83

	modified software to use halt bit.  wins nicely now including stepping thru
	which works by clearing bit in IREG (but not CM).
	However, reading IREG when machine is running seems to clobber the works..
	  I dont think this is supposed to happen, is it?  putting it in single-step-mode
	  seems to help. see code at LAM-HALTED.

	popj-after-next seems to be winning ok..

	tests 0 thru 5 "run" altho they sometimes halt at wrong data
	test 6 tho, now halts immediately claiming wrong-data.  data is really  ok tho.
	 appears that arithmetic tests are unreliable.  dont know how that relates to
	 transfer to randomness problems of yesterday (before halt-bit worked).
         Did check version of memd which was hacked to flush popj-after-next and saw
	 no obvious software lossage.

	ugh, problem with test 6 has nothing to do with main memory.
	jump-equal compares lose.  grossly!  hacked two new tests into SELECT-TEST
	menu to help test this out.
	UINST-COMPARE-LOOP does (incr 5@m), (noop), (JUMP-EQUAL 5@m 5@a 777)
	UINST-COMPARE-PASSAROUND-LOOP is same without the noop.

	both work when single-micro-instruction stepped.
	uinst-compare-loop works sm-stepped, but transfers to randomness when proceeded...
	uinst-compare-passaround-loop fails sm-stepped..

  Observed that ALU.a-m L is being generated by a LS30 gate! this is a serious loss.
	15ns slower than a S30, which we dont have any of.. (BTW, are LS30's used in the
	CADR???)  Also, its overloaded trying to drive a backpanel wire and 5 inputs.

	UINST-COMPARE-PASSAROUND lossage caused by mistake in destination PROM.
	all locations with UINST.write.M set must also have UINST.write.A set as well.

	UINST-COMPARE-LOOP at least stays in loop for a while if execute cycles are doubled.
	  doubling source cycles doesnt matter.  
	Problem was due to oscilating ALUs.  after playing around, finally replaced
	all the F181's with S181's, which caused UINST-COMPARE-LOOP to win completely.

	back to memory test.  Ran completely at half speed!  various mysterious lossage
	at full speed tho...

3/6	Reading IREG will clobber a running machine...IREG is on the cm board, and
	is read out using the mfo, which certainly will confuse the processor.
	-dexter

3/7     hacked new test, UINST-ONES-LOOP, which demonstrates noise problem I think
	is screwwing M-TEST.  I think this is basically the same problem as when
	A and M latches existed, but not so bad.  Ie observed large noise pulses in
	ground and VCC near output selectors, just as "wave" of data hits them from
	ALU.  On next machine, output selectors should be much closer to ALUs, physically.
	For now, I think it will help if output selectors are not enabled until after
	noise has past.  There really isnt any valid data form them to drive to MFO
	until 25ns or so before end of cycle anyway.

3/9    RG
	hacked diagnostic to check macro-ir-fetch, etc.  it actually tries to win
	a certain amount!!   In the process, I removed white wires which were grounding
	out LC.to.VMA.enable and Macro.IR.direct.  This "broke" LAM-TEST-MACHINE.
	It gets a T.HOLD for some reason I didnt quite figure out.
	
3/10	dexter, noble
	added a 330/470 terminator to the mfo bus, which cleaned up the signal,
	but proved too much load for the poor F251s to handle...they were not able
	to drive zeros all the way to the mi board...particularly the maps..fails even
	on lam-test for csm.
	S251s may be ok.  will try again.

3/10   RG
	looking into MID problems.  Macro-ir is not loading properly.  Its made with
	latches, so even if it were to work, its state does not require clocks to change,
	so could happen irrespective or NO-OP, etc etc.  Should be replaced with
	25s07's for next machine.  For now, I guess we need to change to registers and
	a glitch maker...  Making NOOP work will still require special attention...

	decided not to put in mod now.

	problems writing MACRO-IR due to software.  In particular, it you should use
	(lam-execute (read))  not (lam-execute (write)) because actual writing occurs
	during the source cycle.    

	Also, until this is fixed, everyone should be aware that garbage appearing in the
	instruction register can clobber the macro-ir.  The machine doesnt have to be
	clocked or anything...   

	FAST-ADDRESS-TEST-MID runs now.

	status of TEST-MACRO-FETCH-LOOP:.   VMA loads, fetchs macroinstruction word,
	  macro-ir loads,  dispatches to right place for first macroinstruction word.
	  USP increments and appropriate return gets pushed.   However, popj after
	  completion of first macroinst loses.  it decrements USP (which it shouldnt)
	  and transfers to 0 (instead of entry address for second macro inst in word).

	One problem is need to observed both RG and MI boards.
	 need to bring following out to testpoints on MI:
		macro.LC.fetch E27-2(4)
		next.macro.inst E27-15(17)
		MACRO.IR.invalid L E27-12(14)
		Top.level.return.and.next.macro.inst.available  A24-8(11)
		-lambda.master c5-2(4)
		
	RG board
		advance.uinst
3/11	dexter
	fix to pc logic:macro-ir-direct should inhibit pops...macro-ir-direct
	is not asserted if source.us.pop, so you can frob the stack directly
	regardless of the top level bit.  Very slow implementation of this
	feature...rather badly done in WW1 - very little consideration
	given to us.pop as a late signal

	rdm
	Fixes to make NOOP inhibit halts, to make UINST.WRITE.CRAM come from the
	destination proms rather than be decoded off the micro-instruction,
	UINST.WRITE.CRAM to create NOOP.NEXT.UINST, and to have M.SOURCE.Q L drive
	the enable for the Q-register directly.
	The NOOP inhibit halts mod was put in incorrectly, but has now been fixed.

3/12	rg
	grounded interrupt.found.synced (j3-60) on MI board.

	dexter:
	changed the conditions which produce jump.if.true, jump.if.false
	to disregard -jump.r....we were leaving jump undriven in the case of a
	jump.return win.

	working on macro-ir-test-loop.  found uinst.other.halfword needs to be hi
	for current halfword to come out of macro.ir.  Problem then is that
	output of macro-ir-decode ram is not set up for "other" half when needed
	for dispatch to start interpretation of 2nd macroinstruction in word.
	Installed NAND gate to drive uinst.other.half.word from NAND of
	-T.source.cycle and next.macro.inst.on.next.cycle.  

	rg+ngl
	  macro-inst-fetch-loop works!  at "full" (ie one-third) speed even!!
	"minor problems":  combining LC and 1@m in the destination of an uinst
		does not store in 1@m for some reason.
			   single stepping thru with LAM does not work..  software
		fixes needed, presumeably..

3/13   RG
	failure to write 1@m when combined with dest LC due to incorrect signal controling
	selector on input to AM.write.address latch.  fixed.

	Zeroing C-MEM via ucode works! A-MEM too!!

	can single step thru TEST-MACRO-FETCH with LAM.  fix was to single-uinst
	two no-ops after doing passive-state save.

  **     Noticed a pecularity in JUMP logic which I'm pretty sure is a bug.
  **	A failing jump, with the N bit 0, does not set NO-OP.  Thus, if you have

  **	(jump-less-than-xct-next m-x a-x foo)
  **   ((m1) m+1 m1)

  **	M1 gets incremented an extra time as it drops out the bottom of the loop.
    -- nope, I guess its right (or at least the same as CADR) the way it is. --rg


4/18
	WRITING C-MEM FROM RUNNING UCODE SEEMS TO HAVE STOPPED WORKING.
	WHEN TRYING TO CLEAR IT, C-MEM LOCATIONS WIND UP MOSTLY CLEARED, BUT WITH
	SCATTERED BITS LEFT ON.  ALSO, IT SEEMS TO GET RANDOMNESS INTO THE IR
	DURING SUCH THAT IT EVENTUALLY TURNS ON THE HALT BIT AND STOPS.
	(DESPITE WRITING HIGH-CRAM FIRST TO TRY TO AVOID THAT).

4/29
     RDM
        The new debug board has some problems writing all the low four octal places --
        it insists that some of them be left off (e.g., you can write 757, but not 777).
        This is most noticible if you try to write -1.  Note that it doesn't really care
        WHICH bits are left off - so long as a couple are (e.g., you can write 70).  This
        is very weird, and is definately not a problem with the cable, the new station,
        or the old debug card.