help - 11/34 console problem -- CNTRL key behaviour

[Allison]

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