How to diagnose dead Videl?

[Badwolf]

- /ROM2 (/ROM CE) behaves the same as /AS: both on the good and bad falcon, so it /AS stays LOW, /ROM CE stays LOW as well ... again, I need to verify the Combel part however (/ROM2 and Combel /AS)

That's good.

1) it shows that address decoding is at least working correctly on the first access therefore
2) the combel isn't totally dead.

So now it's about measuring XDTACK and XBERR on the pins of COMBEL and seeing if they ever go low after AS goes low (measure at least 16us from AS asserting -- 128 cycles at 8MHz [just to be safe]).

If XDTACK is going low but it's not being seen at the processor, then have a look at GAL U63, which handles that translation.

If they never go low, what's the impedance from those pins to the 5V rail?

If they're high impedance (they should be kilo ohms -- I can't find the exact pull-up on the schematic but others are in the 4.7-10k range), then I think we're looking at either an unhappy COMBEL or there's something getting hot on the board that's attached to XDTACK and driving it high when powered up. That GAL again would be an obvious candidate.

I think the net is closing in.

BW

EDIT: I found the pull up. 1.2k resistor pack. I think it says P12 on the schematic (page 2).

[mikro]

I was busy during the week with other things but I tried to slowly gather notes and pinouts at least. Today I managed to sit down with the Falcon(s) again and: some progress!

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.

I should have listened to you. Let's hear the story.

Thanks to @Badwolf's explanation how /AS, /BERR, /DTACK and /DSACK are related I could easily follow the chain:

- /AS on Combel: LOW
- /AS on CPU: LOW
- /DSACK1 on CPU: HIGH
- /BERR on CPU: HIGH
- /DTACK on Combel: LOW
- /BERR on Combel I interpret as a scream for help (blue - /AS, yellow - Combel's /BERR):

PXL_20250719_173033539.jpg

So who was the naughty boy? U63. I could see XBERR coming into pin 7 but /EBERR not going out of pin 15. Since U63 is exactly the GAL on which the clock patch is soldered on in the good Falcon and I had no spare GALs nor a programmer, I had to ... pull it out of the 3rd Falcon. :D After this exchange /AS was finally happy.

So what did I do? Well of course assembled everything, put RAM & ROM inside and ... no dice. I had no more mercy with the other GALs / MS32 installation, I replaced all four of them to avoid wasting my time even more. Did it help? Nope, still no sign of a display.

What worries me most is that the "videl self test" still doesn't work (RAM & ROM pulled out). Especially when I checked that Videl's VCS is not activated even in the good Falcon in such a setup, i.e. DE should be triggering independently, maybe even independently from everything else.

When / if I find some energy tomorrow, I'll do more measurements. Would be great to know how far can actually system go without working Videl. RAM is of course out of question but maybe it could at least read a long of two from ROM? I guess it depends on relationship between Combel and Videl.

[mikro]

Still not sure whether I feel like firing up the scope today but I did do one interesting test: since my 3rd Falcon has been gutted of all GALs, I got an idea: what happens if I remove ROM & RAM in *this* machine? Do I still get Videl's DE? And the answer is ... yes, I do. So even if the machine is completely unable to work, Videl still generates the 50 Hz signal (interestingly, not in green but all black this time).

So I'm more and more inclining to the conclusion that the bad Falcon indeed has its Videl dead... which brings me to the original question, how to be really sure that this is the case?

There's still one hope -- remember, with ROM in but RAM out, Videl wouldn't generate display either. So I might inspect whether this is the case from the beginning (i.e. not a single DE is fired) or whether ROM presence somehow alter Videl's output after a few cycles (and therefore there's a couple of DEs fired).

Anyway, there could be still other faults so I'd like to make sure that I at least see the first long being read from ROM before going down the rabbit hole of desoldering the Videl (which will most likely fall on @jookie :-P)

[dml]

Looks like you made a bit of progress since I last caught up.

Some of your earlier test results (CPU/COMBEL/RESET/HALT/BERR/AS etc.) were collected with the dead GAL present.

Ignoring the VIDEL for now (dead or not), It might be worth spending extra time checking those upstream circuits again with the working GALS present to see if there is new activity between CPU/COMBEL and maybe even address/data on the input side of VIDEL. Basically see if anything has got un-stuck compared with the first time round. Maybe it will point to the next broken part in the sequence.

[edit] U63 seems to be only used for expansion port output so any change would probably only be due to changing one of the other GALs. But it is interesting this chip got damaged? More on this below.

If the upstream activity looks healthy it will be easier to diagnose a bad VIDEL. If upstream is broken it will be difficult to determine anything for sure downstream.

(Also make sure when checking VIDEL sync output - do this close to the source at the IC itself and not at the monitor socket or any of the output-side components where the signal could be stopped)

[edit]

The fact U63 is gone suggests either a short on one of its own pins (while installing or messing with a booster maybe) or something happened on the expansion port. A short to its own pins is unlikely to cause upstream damage and so the machine should be working. That leaves the expansion port - did somebody perhaps fit something on the expansion with the pins not lined up properly? That could destroy U63 but would also point at some other chips you should give careful attention. The expansion port has 2x VCC pins on one block and 3x VCC on the other. There are different ways those could mis-align to other pins but EINT3, XMFPINT, XIPL2 are maybe the high risk ones. Probably it needs a much closer review though to see what is worth investigating there.

[mikro]

@dml yes of course. I'll try to find out when exactly it breaks. If ROM is being read:

Code: Select all

00000000 : 602e                BRA      $00000030
[...]
00000030 : 46fc 2700      MOVE.W   #$2700,SR
00000034 : 3038 8006      MOVE.W   $00008006,D0 
00000038 : 4e70                RESET     
0000003a : 3038 8006      MOVE.W   $00008006,D0 
0000003e : 31fc 0007 8940 MOVE.W   #$0007,$00008940 
00000044 : 0cb9 fa52 235f 00fa 0000 CMPI.L   #$FA52235F,$00fa0000
0000004e : 660a                BNE      $0000005a

then CPU should make it as far as $e000003e and if that will be the case, I can compare how it behaves with RAM fitted in in both Falcons. Again, I'm not sure how much influence Videl has over RAM access, the service guide states that all memory accesses are controlled by Combel's MCU and that it basically instructs Videl to load *display data*. So who knows, maybe I get to see /ROM3 & /ROM4 (didn't check yesterday). Perhaps loading the display data is exactly the moment when Combel sends +5V on Videl's VCS.

And of course I'm measuring everything on the Videl chip, to my huge displeasure (but that's nothing compared to the Combel pins...)

The fact U63 is gone suggests either a short on one of its own pins (while installing or messing with a booster maybe) or something happened on the expansion port. A short to its own pins is unlikely to cause upstream damage and so the machine should be working. That leaves the expansion port - did somebody perhaps fit something on the expansion with the pins not lined up properly? That could destroy U63 but would also point at some other chips you should give careful attention. The expansion port has 2x VCC pins on one block and 3x VCC on the other. There are different ways those could mis-align to other pins but EINT3, XMFPINT, XIPL2, CPUCLKC are maybe the high risk ones. Probably it needs a much closer review though to see what is worth investigating there.

Oh, good thinking. Indeed, since there was the Mighty Sonic 32 card, it's totally possible that the previous owner "forgot" to tell me that the machine stopped working after such an accident.

[mikro]

Btw, there's also another possibility - I read somewhere that a typical GAL has 20 year data retention. If that is true, the GALs have every right to give up, same as it happened to @sdisla in viewtopic.php?t=7174.

[dml]

EINT3 is tied to the COMBEL #175
XIPL2 tied to the COMBEL #166 and CPU #68
XMFPINT goes to the DSP GAL U44 #19 and the DSP #65 and to the MFP #36 itself

These might go to other places but that's what I saw from the schematic so far.

If a booster was fitted with a pin misalignment of more than 1 it might involve other things but more likely off by 1. Also possible a path for VCC could form through the booster and hit other pins on the expansion but no way to figure that out just pay attention to anything on the expansion that can be compared between machines.


Since you have a stack of Falcons to compare with, you could check the resistance of these nets to GND/VCC (keeping in mind presence of capacitors!) and at least rule out any shorts but maybe could find differences that could point to some damage. If these nets don't show any differences, start looking at other pins on the expansion to compare this way.

[dml]

> I read somewhere that a typical GAL has 20 year data retention

Yes they can of course last much longer but the more of them you have, the more likely you'll hit at least one dead gate when you get past the indicated lifetime.

[mikro]

Since you have a stack of Falcons to compare with, you could check the resistance of these nets to GND/VCC (keeping in mind presence of capacitors!)

Yes, that's in my TODO, @Badwolf also suggested this. Just to be clear, what exactly do you mean by "keeping in mind presence of capacitors", you are talking to a total noob here. :D

[dml]

Yes, that's in my TODO, @Badwolf also suggested this. Just to be clear, what exactly do you mean by "keeping in mind presence of capacitors", you are talking to a total noob here. :D

I don't think this will get in your way measuring the digital signal lines. It could cause some confusion around VIDEL or at some peripherals but just keep in mind there are caps across VCC and GND everywhere and it can appear briefly as a short across both when all the caps are discharged.

If you happen to discover a pin shorted to VCC, it might appear as a brief short to GND which clears. Both confusing but also a clue that's VCC. You just then check directly against VCC and it should be more obvious as a short.

Checking net alternately against VCC/GND helps build a clearer picture of whats going on. Check the net against GND and if you get a brief beep, check it against VCC and expect a long beep.

[edit]

...its a bit more confusing when checking resistance to GND / VCC but really the same situation - just more confusing because you're dealing with numbers and the value will change constantly when you're dealing with a cap. same behaviour though just a bit harder to keep on top of the results.