How to diagnose dead Videl?

Problems with your machine in general.
mikro
Posts: 826
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

dml wrote: Sat Jul 05, 2025 9:15 pmBut you can confirm what the reset circuit output looks like by checking the state of C7 (which charges over the reset delay period) and the output of U1 to U11. If that's switching after a short delay and XRESET from U11 is going high as a result, the bigger problem is not the reset circuit. But the 100R reading is very suspect.
After a few experiments and measurements, I'm more confused than before. When observing C7 vs XRESET, I could see a small delay on both working and non-working Falcons (when comparing two channels at once).

So ignoring the couple of weird oscillations on the working Falcon, there's no huge difference between the two Falcons when it comes to reset signal. Both of the basically go down when they should and go up when they should. Except that the non-working one never makes it to the RESET instruction.

What really killed me today was the fact that I'm unable to measure 10K on R2 anymore even on the working Falcon (same for the other one, of course). Since the Falcon still works and boots, I'm going to assume that it is it was either a measurement error (somehow measuring the pin or D1 instead of R2 by accident?) or something with charged capacitors or whatever.

But now I'm basically at the beginning - no clue what's wrong, no clue what to do.

@dml you meantioned measuring the XRESET level on each IC, do you think it is still a valid start? Then I remember @Badwolf's advice for another user here, they were catching /AS and each of Dx to see whether there is something meaningful on the bus.
mikro
Posts: 826
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

Hmm, looking briefly at AS (pin #4 on EXP port) (and comparing to the working Falcon) has revealed that AS is indeed dead, too -- it just goes HIGH at reset but after button release, it never goes HIGH again.

So yeah, with the CPU I'm exactly where I am with Videl -- IC not doing anything. I refuse to believe that the Falcon was just struck by lightining. :) Any hints what to check next appreciated.
User avatar
exxos
Site Admin
Site Admin
Posts: 28621
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: How to diagnose dead Videl?

Post by exxos »

/AS should go low when reset goes high... Then when /AS is low ROM CE should go low.

In fact the trouble shooting steps here remain the same as the falcon really.

viewtopic.php?t=2362
mikro
Posts: 826
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

I've made a little progress today. Seeing how everything is confusing me, I decided to strip both Falcons to a bare minimum so I can compare only the essentials.

1. As soon as I remove the RAM card, Videl doesn't get activated even on the working one, basically having the same symptoms as the dead one. So that could be a sign that the dead one's Videl isn't necessarily broken.

2. As soon as I remove also the ROM IC, hear this: Videl switches into some kind of test mode, emitting RGB @ 50 Hz in green! When powering up, it even shows a nice "animation sequence", I had no idea at all about this. And unfortunately, the dead one doesn't do this, hinting that it might be broken after all.

However, I'm still not 100% sure that the reset circuit doesn't do some damage there.
exxos wrote: Sun Jul 13, 2025 11:11 pm /AS should go low when reset goes high... Then when /AS is low ROM CE should go low.
Indeed, I have verified this on the working Falcon. This is how it looks with no ROM and no RAM (yellow - /AS, blue - /RESET, still not sure why I'm seeing this first spike of 5V):
PXL_20250714_070044123.jpg
PXL_20250714_070044123.jpg (232.43 KiB) Viewed 612 times
However on the broken Falcon:
PXL_20250714_070740268.jpg
PXL_20250714_070740268.jpg (230.51 KiB) Viewed 612 times
/AS never recovers from the LOW.

I have verified the relationship between /AS and /ROM CE, they both go low, even on the broken Falcon.

When measuring for how long /AS stays HIGH on the broken Falcon, it's about 300ms. This seems to be the same on power up and on reset button (if I push and release it quick enough) so that's probably the /RESET delay.

So I don't know... what are the chances that both CPU and Videl are dead, right? (I'm assuming here that dead CPU doesn't affect the Videl's test mode).
User avatar
exxos
Site Admin
Site Admin
Posts: 28621
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: How to diagnose dead Videl?

Post by exxos »

Verify the ROM is good. Check all data pins on the ROM when AS goes low and see I'd you get the expected data. My link shows how to do that.
User avatar
dml
Posts: 853
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

mikro wrote: Sun Jul 13, 2025 10:35 pm @dml you meantioned measuring the XRESET level on each IC, do you think it is still a valid start? Then I remember @Badwolf's advice for another user here, they were catching /AS and each of Dx to see whether there is something meaningful on the bus.
Yep I would start with the XRESET and XHALT signals.

Make sure XRESET reaches all the chips that use it and that the signal is in the correct voltage range at the relevant pin of each chip, not being pulled down/up significantly by any one of them. Chances are very high this is all ok but if not, you'll waste a lot of time on other things.

XHALT is output by the same U11 reset buffer, on a machine-reset but the shared HALT signal can also be asserted by the CPU (pin 129?). If HALT remains low after reset instead of following XRESET, it will most likely be the CPU - which could be an upstream fault or the CPU itself. It could be that the CPU is trying to work but suffered a error. This can even be an early clue to a working CPU.

Those are the simplest signals to check.

I would also look at the busmaster signals BR/BG/BGACK since these can stop the CPU accessing ram - the COMBEL and SDMA can take control (but not the VIDEL, given what ijor explained recently). It may be possible to tell if e.g. the CPU requested the bus but did not succeed due to a stuck component, so it will never fetch/execute the RESET instruction....

mikro wrote: Sun Jul 13, 2025 10:35 pm So I don't know... what are the chances that both CPU and Videl are dead, right?
Unless someone powered the board in reverse or with 12v, they are not closely related so I think it is unlikely they would both fail together.

Remember also the COMBEL sits between all these things and any problem there is a dead Falcon - CPU can't access RAM, VIdel won't fetch... nothing. There are plenty of similar problems which don't need to involve COMBEL but statistically it's more likely to be faulty than the two other ICs together.

It does seem like a dead VIDEL can't cause the issue you are demonstrating on the scope. It is too far upstream. So I would ignore VIDEL for now and focus on the CPU/RAM/ROM/COMBEL, maybe also SDMA as potential bus master hog.


I have seen a couple of boards recently with randomly unsoldered legs on one or more of these ICs and it is completely invisible. You can't diagnose it by eye and it is difficult with just a microscope - you need to push each pin from the side or do a cont. check from shoulder to pad on every pin, to find them. It is very tedious but something you can rule out with some certainty and not have to repeat later.

A cont check on the MFP and some other peripherals is also a good idea while you are at it. Some of them can interfere in non-obvious ways. More likely you would be seeing more CPU activity first in this case but still worth just ruling all of that stuff out early. The QFP type of surface soldering for the MFP also has the unsoldered-legs problem, but under the IC.

There is also the DALLAS chip which sits directly on the data bus lines 0-7 with a chip-select from the COMBEL. There have been cases where a dead NVRAM can hold the machine on a black screen (not exactly sure how but it has pins on the bus - maybe just toggling RGB/VGA but could be more to it in some cases). I don't think I have experienced that one - more typically you get boot problems and bad settings - but its another thing which would be good to eliminate early, if not already.

I would also be tempted to do some easy stuff early - make sure there is no FPU present (but I think you did strip it down already), exchange the socketed ROM & the GALs with the working machine for a test. That gets rid of a few more simple things. Chances of damaging the ROM/GALs is low and you can always make more of them as a last resort.
mikro
Posts: 826
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

exxos wrote: Mon Jul 14, 2025 9:25 am Verify the ROM is good. Check all data pins on the ROM when AS goes low and see I'd you get the expected data. My link shows how to do that.
I saw it, yes. ROM itself is still removed, so that shouldn't influence anything. As we know, /AS is low and in that moment we should measure Ax pins... which I did and all of them are low (random two Ax pins; yellow = /AS):
PXL_20250714_085843605.jpg
PXL_20250714_085843605.jpg (215.79 KiB) Viewed 602 times
PXL_20250714_085722342.jpg
PXL_20250714_085722342.jpg (265.17 KiB) Viewed 602 times
So that could hint that the CPU is not really dead but why the /AS in LOW then, right? Should I see some data (once I put ROM back in) even when /AS is still low?
User avatar
exxos
Site Admin
Site Admin
Posts: 28621
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: How to diagnose dead Videl?

Post by exxos »

If address lines are switching, which they appear to be, then the CPU is at least running otherwise you wouldn't get ROM CE going low with /AS.

But it's odd the address is changing before /AS is going low.. Are you sure AS = yellow?

All addresses have to be zero when the first AS goes low. Then the cpu will count on the first lower address lines to get data from ROM.
User avatar
dml
Posts: 853
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

mikro wrote: Mon Jul 14, 2025 10:01 am I saw it, yes. ROM itself is still removed, so that shouldn't influence anything.
Yes I see you already ruled out ROM with the weird greenscreen test o_O - but before you restore it for other tests, at least confirm it in the other machine or swap them so you know it's not going to become a second fault on top of your main fault.

(As mentioned above, I would do the same for anything still socketed since you have the opportunity)

Looks like exxos has you onto something with /AS... :)
mikro
Posts: 826
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

exxos wrote: Mon Jul 14, 2025 10:04 am If address lines are switching, which they appear to be, then the CPU is at least running otherwise you wouldn't get ROM CE going low with /AS.
Yes, that was my assumption (after reading your guide), too.
But it's odd the address is changing before /AS is going low.. Are you sure AS = yellow?
I am sure however I agree it looks very odd. This is the same scale from the working Falcon:
PXL_20250714_092110104.jpg
PXL_20250714_092110104.jpg (248.73 KiB) Viewed 582 times
All addresses have to be zero when the first AS goes low. Then the cpu will count on the first lower address lines to get data from ROM.
Technically speaking, this is true, we do see the all addresses are zero when /AS = LOW. So what's next? Putting the ROM in and trying to see some data lines? When exactly should /AS go HIGH again, after executing the first instruction? If so, why does it go high even without ROM on the working Falcon?
dml wrote: Mon Jul 14, 2025 10:12 am before you restore it for other tests, at least confirm it in the other machine or swap them so you know it's not going to become a second fault on top of your main fault.
That was a good idea and fortunately, both RAM and ROM from the broken one work in the good one.

Unfortunately, I can't swap that many things around - both Falcons have a clock patch so easily I can swap maybe the three GALs and even that is complicated by the fact that I had to rewire the Mighty Sonic 32 installation to U68 (to get back BG and BGACK) so... mess, just a mess.
Post Reply

Return to “HARDWARE ISSUES”