Broken reset circuit / 555?

[mikro]

Certain Atari fan nudged me into opening my *second* broken Falcon tower (with a CT2B installed) so while doing that, I decided to finally check its shape, just in case that's easily repairable so I wont be losing too much time with the first one.

The first symptoms were quite similar to viewtopic.php?t=7810 -- no DE on Videl, nothing on monitor, nothing's happening in both Normal and Turbo mode but I do see /AS and friends being alive, even activating /ROM3 (but that's that, it didn't make it to the diagnostic cart's serial output). So I'm like what are the odds that on both of them is the Videl dead, right?

Fortunately I occurred to me to start from the beginning, i.e. measure /AS vs /RESET and imagine my surprise when seeing this on U1's (555) pin 3:

reset_u1_3.jpg

Every 2us or so there's a new reset pulse. Huh.

This is propagated everywhere, most notable the CPU and Videl, so no wonder that Videl doesn't output anything.

For starters I would like to ensure one thing: seeing this on the 555's output pin (and U11's input pin) means that there's no way this is caused by a Falcon IC, right? Because if XRESET (U11's pin 2) was LOW due to some IC, it couldn't reach the 555 due to U11 being an inverter which goes only one way, correct?

[dml]

> it couldn't reach the 555 due to U11 being an inverter which goes only one way, correct?

That seems correct - I'll check the schematic to be sure but the inverter/buffer should be isolating the 555 output from the ICs using the RESET net.

Only the 555 itself and upstream - its VCC supply and inputs - should be interesting here.

[edit]

yep - no feedback to the 555 from the RESET net. It is output-only.

[mikro]

@dml From I remember from my clock patch research, one of the reasons why inverters are used there is to avoid signals going backwards. So that's what my expectation is based on.

Also, I presume this doesn't automatically mean that it is the 555's fault. I.e. one bad resistor, capacitor or diode can confuse it enough to produce such weird results.

[dml]

@dml From I remember from my clock patch research, one of the reasons why inverters are used there is to avoid signals going backwards. So that's what my expectation is based on.

Yep - buffers are used to isolate input from output and to duplicate signals while also keeping them isolated from each other (or invert, or make a small delay or some other uses). Should not be feeding backwards (unless U11 is fried in a very special way e.g. shorting the 555's output to ground - but then it would not propagate an output of its own so that's easy to rule out)

Also, I presume this doesn't automatically mean that it is the 555's fault. I.e. one bad resistor, capacitor or diode can confuse it enough to produce such weird results.

Yep - 555 uses capacitors for timing/pulse behaviour, not just decoupling / filtering. The resistors also involved in that. Check everything around the 555. But also make sure its VCC is not too low, and not dipping with the same waveform in case there's a power problem.

[mikro]

Yep - 555 uses capacitors for timing/pulse behaviour, not just decoupling / filtering. The resistors also involved in that. Check everything around the 555. But also make sure its VCC is not too low, and not dipping with the same waveform in case there's a power problem.

VCC looks good, resistors look good (just to be on the safe side, I compared the results to the working Falcon and not schematics so any "magic" there is applied equally) so that leaves the capacitors and the 555 itself. Too bad one can't measure caps without removing them.

[dml]

Too bad one can't measure caps without removing them.

Lift one side only - the non-groundplane side (not always the -ve side! but should be in this case).

The groundplane side is always much more difficult to desolder.

[mikro]

Armed with experience from viewtopic.php?p=132261#p132261, this literally begged to be look at again and I'm glad I did.

At the first sight there's nothing wrong with the /RESET (blue):

PXL_20250809_165151467.jpg

However when zooming in... short reset push:

PXL_20250809_164917227.jpg

We can see it is the same lonely pulse as in my working Falcon. However during a long reset push:

PXL_20250809_164947835.jpg

We can see that while my working Falcon had there only one additional stray pulse close to the rising edge, here we get:

PXL_20250809_165113999.jpg

So it's not in a reset loop going forever, it's just a crazy amount of short pulses before the final rising edge.

As the better behaving reset signal is in the falcon which has some of the caps and resistors replaced around the reset circuit, this extreme behaviour can be perhaps also attested to subobtimal caps.

Since I can "massage" the reset circuit into a normal state (via a short reset push, leading to only one stray pulse), I don't think this is what makes this particular Falcon non-working. So another investigation coming up....

EDIT: Btw, this also implies that it doesn't look very good for this Falcon's Videl either as I'm not getting anything on DE when both ROM and RAM is out....

[mikro]

While waiting for the CPU replacement for the first Falcon, I went back to this one...

This one is pretty special because I can see that the code makes it quite far away before giving up. Also, that makes it quite annoying to analyse on the scope, even though I have learned how to store long waveforms. I even found a nice viewer for them but still, I have to do all the 24 + 16 signals by hand, so that's roughly 40 * (16, 32, 64, more?) = more than 1000 1s and 0s to write down. When everything fails, perhaps I'll try to assemble the LA kit for the RPi which I purchased a couple of months ago.

So, being lazy to do the hard work, I went back to the basics: measured voltage on all Ax and Dx during reset (yup, using duct tape) and what do I see? D5 is for some reason totally wrong. 3.44V with the button not pushed, 2.53V with the button pushed. Nice!

So I made a list of all places connected to D5:

cart 14
exp 10
eprom 16
ide 7
fpu 45, 66
cpu 102
===
DS1287 9 (U64)
68901 46 (U31)
combel 169
videl 28
u59 14
u61 7
u66 14
sdma 130
85c30 4 (u13)

Luckily, I can rule out both CPU and FPU because they are on the CT2 board and not on the PCB anymore, so that makes it two suspects less.

When I tried to measure resistance between VCC/GND and the pin in question, similarly as with the first Falcon, I couldn't see anything conclusive: 2.42R against VCC / 2.76R against GND basically on all of them.

So my favourite discipline, voltage measurements! Spoiler alert: all my measurement devices suck:

Code: Select all

                EXP	Combel	U64	U31	Videl	U59	U61	U66	U13	SDMA	Winner
Scope (V)	2.59	2.53	2.53	2.53	2.53	2.53	2.52-3	2.52-3	2.52	2.53-4	U61, U66, U13
Meter #1 (V)	2.46-7	2.48-9	2.47-8	2.45-6	2.48-9	2.47	2.47	2.46-7	2.45-6	2.46	U31, U13
Meter #2 (V)	2.482	2.479	2.478	2.483	2.48	2.488	2.486	2.483-9	2.479	2.478	???

The one which pretends to be the most precise one (three decimal points) seems to be completely lost. Anyway, nice to learn it this way. ;)

So perhaps tomorrow I'll start with lifting pins ... I'm reluctant to start with U13 and U31 as those are definitely not the easiest ones so maybe I'll just try U59, U61 and U66 first. Interestingly, Videl now doesn't show up as a primary suspect despite the fact that DE is not active at all. So yeah, maybe I'll start with Videl, despite all the measurements.

[exxos]

I haven't been following much but if you are holding the reset button in and you are getting pulses, are you sure the reset switch just isn't simply bad?

[mikro]

I haven't been following much but if you are holding the reset button in and you are getting pulses, are you sure the reset switch just isn't simply bad?

The series of reset pulses appears after I release the button, so I'm inclined to say that the button is fine. But that's an issue for another time, if I quickly push and release the button, the pulses are not there. Now I have to trace the source of broken D5.