28 Feb
2014
28 Feb
'14
8:11 p.m.
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