How to diagnose dead Videl?

[dml]

So it must be the pins on PCB or something which is understandable: this Falcon is old and beaten, used as a dev machine for the Phantom accelerator. Somehow I managed to stabilise it but no more RAM card removal on this Falcon. Of course, I'll reflow it later but surely not now.

This happened to me too! I have run into a version of that problem on two boards so far - I also warned somebody else about it in another thread here - anything that looks like faulty RAM or databus, first check the state of the memory expansion pins & PCB solder joints....

[mikro]

... drum roll ...

Seeing my bad luck today, I went to easiest route, catching the address signals:

Code: Select all

000000
000002
000004
000006
0e0030
0e0032
0e0034
0e0036

However after this, it's just a mess:

Code: Select all

2E03FC
000020
000022
2E03FE

I'm pretty sure it is because of this weird timings:

mess.jpg

The first three edges are from the 5th, 6th and 7th address (counted from 0) but then you see, it's EXTREMELY tight. Basically nearly all 1s in the 8th and 11th address and all 0s in the 10th address look like this. I'm most confident about the 000020 address which itself is bogus.

Since this is happening only after fetching 8 data words, I can't think of anything else than CPU being crazy. Even if the 0xFFFF8006 caused some horrible error, CPU should't just go haywire. It should just jump into its exception handler at least, if nothing else.

[dml]

Then maybe trying the MightySonic isn't a bad idea. It breaks the rule of keeping things simple - but as a test, it could be worthwhile.

If it doesn't work though, you can't really conclude much. There could be multiple faults on the MS also.

Or just change the CPU... Do you have a replacement?

[mikro]

On pin 3 (OUT) of the 555 timer I'm getting +5V when I push the reset button in and 0v a short delay after I release it. I don't see any other oscillations.

I'm using ROLL mode on the scope to record the history over 200ms or so.

I'll check now what XRESET is doing on output from U11 - that could be different as its shared with the other ICS which can pull it low.

I fell into this rabbit hole again but this time armed with more experience so I decided to find out what is going on my both Falcons. I have the probes on U2#2 and U11#2 (/RESET), so I'm not interested in the RESET instruction at this time.

1st column = good Falcon
2nd column = bad Falcon
Yellow = U2#2
Blue = U11#2 (/RESET)
As we can see for the first two rows (measuring at 100ms) both Falcons behave as expected: the 1st row is a long reset push, 2nd row is a short reset push. However check out the other rows:

reset-merged-resized.png

On the 3rd (long push) and 4th (short push) row we can see what I was referring to in my previous posts: two pulses (long push) and one (short push) pulse, respectively while ironically on the bad Falcon we can see that everything is still OK. Only after *really* zooming in (2us) we can see that even the nicely behaving reset circuit does have some tiny little pulses over there.

@dml if you have a naked Falcon somewhere, can you repeat my tests? I.e. set the trigger on the rising edge of /RESET on U11#2 on a 1us scale and see whether you get just one LOW->HIGH transition?

Anyway, now I can focus on the more interesting stuff. ;)

[dml]

I'll give it a try - but you caught me exactly while I'm trying to use the Falcon to test stuff so I should finish that first :)

[dml]

Here's the result from my machine... U11, pin#2, one transition on releasing resetbutton, low-high.

(the trigger is on the low-high, so I had to add a trigger delay offset to see anything before that)


BTW it looks to me like you are using 1x scale on your scope (2V/div). You may want to switch to 10x mode on the probe and switch the scope down to 0.2V/div because the probe will have 10x the impedence (resistance) and less likely to interfere with the signal or 'round off' the square edges. I doubt it is the cause of what you are seeing but it is usually better to use the higher impedence option for more reliable measurement.

(When you mess with probes you should also adjust the tiny compensation capacitor on the probe to get a perfect squarewave before measuring anything - you can do that using the reference squarewave output from the tiny signalgen terminal on the front of your scope - you can see it in my pic at the bottom, the 'probe adjust' terminal).

reset.jpg

[mikro]

Here's the result from my machine... U11, pin#2, one transition on releasing resetbutton, low-high.

Cool. So it is supposed to be clean. When (if ever ;-)) I fix those two broken birds, I'll try to measure all my other Falcons, I'm really curious what's causing it.

BTW it looks to me like you are using 1x scale on your scope (2V/div).

From what do you have this impression? As I know next to nothing ;) I can only tell that when I push "CH1" or "CH2" in my scope, I see: Probe "10x" and Volts/Div: Coarse. And then the probes offered with the scope have 1x/10x switch on them, and it is set to 10x. The other probes I use for tiny pins (thanks @agranlund): https://sensepeek.com/sq100-100-mhz-han ... cope-probe operate in default 10x more as far as I could understand.

Also, I have calibrated all of them to be as close to a square wave as possible.

Is there something else what I should be looking for?

[dml]

Nope that all sounds good to me. I just went with what I saw on your scope screen - but it depends on the scope and how it is configured for the probe.

:thumbsup:

[mikro]

Today I tried to *finally* compare the good and bad Falcon's data/address signals which required learning about the long memory depth. :-) I have stitched A2 (yellow) and /AS (blue) together, first row = good Falcon, second row = bad Falcon:

good_and_bad.png

We can see that bad Falcon's A2 falls down way later (about 1us), barely making it to the first /AS rising edge. Then everything is OK for 8 pulses (addresses) only to see that on the 9th bad Falcon barely makes a "1" and A2 falls down (it should not). Also, the 8th pulse is obviously way shorter on bad Falcon...

I gave it a thought again:

- I could measure all signals (and ideally store them digitally as CSV/WMF) on both Falcons and see whether there isn't some super-obvious difference

- I could replace the CPU (has to order a new one...)

- I could replace the CPU with the MS32 (with the risk of being faulty and maybe even hostile to the Falcon...)

or...

OR !!!

- I could take my CT60 and boot it in 060 mode to rule out a CPU issue (why I hadn't thought of it sooner????)

And lo and behold..................

PXL_20250810_090345386.jpg

[dml]

\o/