2 Mar
2014
2 Mar
'14
5:06 a.m.
----- Original Message -----
From: "Rick Bensene" <rickb at bensene.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, March 01, 2014 4:11 AM
Subject: RE: PDP 8/e, RK8E Weirdness
Hi
The problem is with the gating of the IOT ( 6RK4L) before its applied to
the 74161 as CLK (2),
on drawing M7105-0-1 REV B , MAJOR REGISTERS (D06)
this is done by E47 , E41 and E28, the problen is that they are taking the
6RK4, the IOT, and trying to truncate it with a modified TP3, and if this
TP3 timeing is a little off then you get a spike at the trailing edge.
Different revisions of this board seem to have different ways of generating
this TP3, and mine has a wire patch in place .
Have a look at E18(2), the CLK while doing an DLCA scope loop and see what
you get.
My fix was as follows, "piggy back" a 7474 onto E41, just the gnd and
power , 7 and 14, bend the rest of the pins away.
On the 7474 connect both the D(2) and the CLR (1) to E41(10), then connect
the CK(3) to E41(9).
Cut the track from E41(8) to E28(12). Connect fron the 7474 op(5) to
E28(12).
The result of this is to latch the TP3 pulse so it cant go low before the
end of the IOT.
This shoul be it, I had to decifer my notes and look at the board so I hope
iv got it right!
Lets hope this is your problem, the RK8E sure is fun to work with , I had to
change several IC's to get my set working at all.
Cheers
Dave
David Humphries
writes:
(I am posting this reply to the list rather than via private Email just
in case folks are interested in following the thread).
That sounds like the problem I had with my RK8E.
It manifested itself
by
the data break address register being set to 1
greater than it should
have
been after a load and therefore being 1 out after
that, I think this
could
give the symptoms that you have.
It sounds very much like this could be what is happening.
The cause was a race hazard in the generation of
the load pulse which
resulted in a spike after the pulse, the pulse would load the correct
value
then the spike would increment it. Examiniation
of the drawings showed
that there had been several ECO's in this area so I think this may
have
been a long standing issue. As it's a race
(i.e., a timing) issue,
It's quite
conceivable that it did not show in another
system, mine sometimes
worked, sometimes not.
The drawings I have don't have anything in the way of ECOs noted. I'd
be interested in finding out what ECOs were made more from a curiosity
standpoint than anything else, since it seems that the ECOs that were
made didn't seem to alleviate the issue. I'll also have to look at my
boards to see if there are any signs of ECOs in the IOT decoding or LOAD
or CLOCK inputs of the 74161 counters that make up the Current Address
register.
The behavior of my setup is very consistent -- as far as I can tell, it
never works properly.
It could be that there are subtle timing differences in the MD bus
signals on my CPU that feed the IOP decoder on the M7104 board that lead
to a large enough spike occurring on the 6RK4 signal generated by the
decoding of the DLCA (load current address register) IOT (6744) versus
the other system that the RK8E was tested good in.
I corrected the problem by adding a 7474 latch,
this cured it.
I'd love to know how you patched this in, e.g., how the 7474 was wired
into the circuit to get rid the transient.
It'd certainly be good to know which signal you were monitoring to see
the spike (was it the 6RK4 L signal?), and that way I could perform the
same measurement and see if I see the spike.
Now this was some time ago so I will have to
look at (and find) the
sparse
notes I made at the time, I can also look at my
RK8E set to see
exactly
what I did.
That would be most appreciated.
Not that its very informative but there is a pic
of the spike here
https://www.flickr.com/photos/78027915 at N04/8068780053/
Wow, the spike was quite obvious. I can see, based on how the 74161
counters that make up the current address counter are configured, that
they would end up loading the correct data, then incrementing as a
result of that spike, causing the first word of the transfer to be off
by one in terms of the memory address that would be loaded.
I'd be very appreciative if you could, when you have the time, either
find the notes, or look at the patch you made, and send information
along on how I may be able to make the same modification on my RK8E.
It would be so cool to get the RK05's running on the system. While
using the system the RX01 floppies brings back a lot of memories (my
first real job was doing programming on a PDP 8/e system with RX01
floppies back in 1976), it is rather tedious in terms of how slow they
are, and how little data the RX01 floppies store. I guess I was a lot
more patient back then (I was 18 then) than I am now. It's not like the
RK05s are speed demons, but they are so much faster than the RX01s and
actually store a reasonable amount of data.
Thank you so much for your response -- it does sound like your past
experience may be what is what is going on with my setup.
Best regards,
Rick Bensene