Another IC I Can't Identify

[Brent Hilpert]

On 2018-Nov-11, at 2:04 PM, Rob Jarratt wrote:
>> -----Original Message-----
>> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
>> Hilpert via cctalk
>> Sent: 11 November 2018 21:50
>> To: General Discussion: On-Topic and Off-Topic Posts
>> <cctalk at classiccmp.org>
>> Subject: Re: Another IC I Can't Identify
>> 
>> On 2018-Nov-11, at 1:32 PM, Rob Jarratt wrote:
>>>> -----Original Message-----
>>>> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of
>>>> Brent Hilpert via cctalk
>>>> 
>>>> On 2018-Nov-11, at 11:52 AM, Rob Jarratt via cctalk wrote:
>>>>> Thanks for all the replies. If that is indeed what it is, then I
>>>>> still
>>> have not
>>>> been able to find the source of one of the signals that seems to be
>>> causing
>>>> the Reset, every pin I have found so far is an input, I have not
>>>> found it connected to the output of anything yet :-(
>>>> 
>>>> 
>>>> Have you tried the reverse? : follow an origin that you know should
>>>> be controlling reset, such as the power-on indication from the PS,
>>>> and see if
>>> you
>>>> can trace it to the CPU.=
>>> 
>>> I have already found that source and it all looks OK. I think I have
>>> identified another input to a NOR gate that is high and causing the
>>> reset, but I can't find where it comes from.
>>> 
>> 
>> Perhaps I'm not clear on what you're saying, I was taking you as meaning
> you
>> hadn't found a source driving the reset line.
>> While you've found a PWR-OK signal and it looks good, have you found how
>> it connects to the reset line?
>> 
>> Reset-line arrangements on small machines aren't usually that complicated.
>> (Usually the power-on signal source is a series RC combination (often with
>> additional discretes such as diodes) between a power-bus and ground).
>> 
>> Perhaps put up an image of the schematic you have so far.
> 
> I have posted an image here:
> https://rjarratt.files.wordpress.com/2018/11/system-board.png
> 
> At the far right you will see a "To F11 Reset", my understanding is that
> this is active High. I have determined that the D input on E141 is always
> high. The CLR input on E141 is periodically set, thus causing a pulsing high
> output on E141, leading to a pulsing Reset on the F11 chipset.


Well that (the circuit, as much as is presented) is quite bizarre.
There's not a lot to make sense of from what's shown.
If it's really that complex then the question is why? What is all that complexity intended to do, for the sake of reset?
Without understanding the intention you're stuck tracing your presumed faulty signal back hoping (luck) that you encounter a fault along the way.
But it may be that the pulsing is not itself a fault, but an intended (perhaps looped-back) consequence of some more-distant condition (ala the watchdog timers others were mentioning earlier).

Aside from continuing as you have been and hoping that you luck out, I'd be looking at options such as:
	- RE the whole thing and analyse it in entirety to figure out the intended reset operation.
	- Find the docs on the CPU and see if they could provide some explanation as to the intention, based on the CPU reset functionality.
	- Examine the schematics of other machines using the same CPU (as others have mentioned) to see if they have similar complexity around reset.
	- Double/triple check to ensure you haven't gone astray in the tracing.

A note regarding E141, the 7474 (and following 74174) are edge-triggered, not transparent, and will require activity on the CLK input to produce a pulsing output (if PRE is fixed high), activity on the CLR input is not alone sufficient.