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!
thanks,
- Henk, PA8PDP.
This message and attachment(s) are intended solely for the use of the addressee and may
contain information that is privileged, confidential or otherwise exempt from disclosure
under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this
message to the intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by
telephone and with a "reply" message.
Thank you for your cooperation.