help - 11/34 console problem -- CNTRL key behaviour - test-drb@ccmp.vtda.org

10 Nov 2005

...

Subject: RE: help - 11/34 console problem -- CNTRL key behaviour
   From: "Gooijen, Henk" <henk.gooijen at oce.com>
   Date: Thu, 10 Nov 2005 09:03:40 +0100
     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>

Tony wrote: 

   just a
short question, I have seen so much that I start doubting 
 everything :-( After you pressed the CLR key on the 11/34 
 console (to get a clear start point), if you *only* press the
 CNTRL key, nothing should happen, right?  
 Right. The CNTRL key is a bit like a shift key, and should do 
 nothing on its own.

 To answere one of your other posts, I would expect data to be 
 written ot the display latch quite frequently (of the order of ms)
 _but_ the write pulse will be narrow (a few us at most), and if
 you've got the analyser set up to sample for long enough to display
 several display scans, you might well miss some of the write pulses
 because they occur between analyser samples. I think the K100D has
 'gltich capture' for just this sort of problem, try selecting it for
 the input you use for the write pulse.

 -tony 
Ok, so the CNTRL key behaviour analysis is a good point to start with.

Yesterday evening I checked the latch that gives the NUM 1-2-3
signals, and the buffer that is behind it. The in- and output signals
are OK, although it is *constantly* '110', which matches the display
value "666666".  On the LA (set to sample at 1 msec) I did see *one*
pulse on the CLK pin of the latch.  My guess yesterday evening was,
that is not correct as just *one* pulse in 1000 msec is way to low
for a good refresh rate, just as you say Tony. It did not occur to me
that the single pulse was "by luck" detected by the LA. If the LA sees
*one*, I should see more, I'd guess.  I do remember that I had to turn
up the brightness control of the scope to see the thin CLK pulses ...
I will put a picture on the webpage tomorrow.
The battery of the camera is recharging.

Your initial remark about a failing RAM chip is still in the picture,
as the value to display is taken from the first 3 locations of the
RAM.  BTW, the operator/maintenance manual has an error in the memory
allocation. It shows that the first byte is for the display, but it
is actually the first 3 bytes. So the rest of the picture can not be
correct either ... The assembler source listing proves this. Every
time a digit must be set on the output port, the 3 memory locations
are shifted 3 bits. That means with 6 digits, that at the end the
total shifted bit count is 18. The code corrects the value in the
3 memory locations by shifting 6 bit positions when the complete
6 digit number is sent to the output port.

I am getting tempted to install the totally dead M7859, and have a
look at it, with the new knowledge build up from this module. May be
its is just a defective 8008, but I am afraid that if I get the dead
M7859 working, this weird defective one will end up on the pile of
things "I must do, when I get the time" ...
But I will first inspect the two RAM chips! 4-bit data in, 4-bit data
out, 4 address bits, one select pin and one clock pin (the WE* pin
is tied to GND). Should be possible to see it all with the 16 channels
and make a conclusion of the RAM's condition. You might have been
correct from the beginning, Tony! 
Never seen a dead 8008.  I thought I'd killed one (at $180 then!) by 
installing it backward and then tossed it on the floor in the engineering 
lab. some days later after pulling from the bottom of my shoe I tried 
it again and it was still alive.

The ram however is definately suspect. But I've seen IO messups with 8008
and with scanned displays and keyboards are harder to look at.

It would be goof if you could run a different program and see it's results.
We used a set of ROMs all different to test.  They were short programs that
would either loop or do something and halt. For example we had one that would
write (this was a time display) 00:00:00 then increment all the displays
without doing anything else.  Another would write a 8 tot he last display 
and halt.  the most useful ones were those that would repeatedly loop input
or output to a port.  Very handy as back (1973) then logic analysers were 
not to be had and a 15mhz dual trace scope was the usual tool.

Allison