How to diagnose dead Videl?

[mikro]

Correct @dml. I have also corrected the typo.

[dml]

Correct @dml. I have also corrected the typo.

:thumbsup:

So whatever happened, took out more than the VIDEL :( that's definitely some kind of 'power excursion' accident

- something plugged incorrectly into an expansion port / header
- famous screwdriver accident (falling onto the board while powered on)
- etc.

Hmm.

So you want to check if the CPU is outputting RESET - but can't lift that pin because the CPU won't get its initial reset along with the rest of the board. There might be a way to rig this (with a diode, facing the XRESET side) but its probably not the simplest thing to set up and may not work anyway....

But thinking about this.... either the CPU is not successfully outputting RESET (pulling it low) or it is trying and failing because of some other problem. If it is some other problem keeping XRESET high, it would have to be to a VCC short or similar via another dead IC - and that's unlikely, otherwise the initial RESET would always be HIGH, instead of LOW-HIGH.

So it seems like the CPU is not bringing RESET LOW? And it can only be the CPU to blame for that?

Maybe @Badwolf or @exxos has some ideas here

[mikro]

Hmm, this really doesn't look good. As observing data signals isn't so hard, I decided to go with that one first. Basically we are interested to see where this sequence breaks:

Code: Select all

_os_entry:
[00e00000] 602e                      bra.s     _main
[00e00002] 0404                      dc.w 0x404
[00e00006] 00e00030                  dc.l _main
           00e00000                  dc.l _os_entry
[00e0000c] 00008f9a                  dc.l _endvdibss
[00e00010] 00e00030                  dc.l _main
[00e00014] 00e49424                  dc.l _ui_mupb
[00e00018] 03081993                  dc.l $03081993
[00e0001c] 00ff 1a68                 dc.w $ff
                                     dc.w $1a68
[00e00020] 000056ba                  dc.l _root
[00e00024] 00001187                  dc.l _shifty
[00e00028] 00006ee4                  dc.l _run
[00e0002c] 00000000                  dc.l 0

_main:
[00e00030] 46fc 2700                 move.w    #$2700,sr
[00e00034] 3038 8006                 move.w    ($FFFF8006).w,d0
[00e00038] 4e70                      reset
[00e0003a] 3038 8006                 move.w    ($FFFF8006).w,d0
[00e0003e] 31fc 0007 8940            move.w    #$0007,($FFFF8940).w
[00e00044] 0cb9 fa52 235f 00fa 0000  cmpi.l    #$FA52235F,cart_bas
[00e0004e] 660a                      bne.s     $00E0005A
[00e00050] 4dfa 0008                 lea.l     $00E0005A(pc),a6
[00e00054] 4ef9 00fa 0004            jmp       $00FA0004

So far I have confirmed 602e, 0404, 00e0, 0030, 46fc, 2700, 3038 and 8006 to be fetched. After this, things seem to go wrong: 2711, ffff, ffff, 0e00, 0030, 00e0, 0030, 0000.

The 2us gap in previous images is the first "0030" word. Even without any clue what the first three words are supposed to be we can see that most likely some kind of fault has occurred so the PC is back at _main. But how, why... /BERR and /HALT are quiet as usual.

On top of it, some of the signals are really suspicious. On more than one occasion I could see the first (from the left) bit of the 8th word (counted from 0) being just 4V:

PXL_20250805_080847762.jpg

Or a data line's logical 1 being seen at the last possible moment by /AS (again, only in those two specific bits):

PXL_20250805_080225749.jpg

Weird stuff. I'll compare the traces with my working Falcon.

Is there a way to see when the CPU actually *executed* (not fetched) the instruction word? That way I could see whether it made it after "move.w ($FFFF8006).w,d0" or not.

[dml]

If you are watching data only, it must be back at 00e00006 not _main i.e. the opcodes just after the initial branch and $404.

This could also be confused slightly if the data cache is defaulting to ON - or if an exception occurred - because it can be fetching stuff that isn't in the logical instruction stream.

I don't remember if the dcache is enabled by default - it probably isn't until the OS sets it - but an exception could be causing the $2711 if this is an automatic save of SR to (sp) and then followed by some unexpected stuff pushed on the stack?

[edit]

Yeah it may be the $FFFF8006 read has caused an exception but not necessarily BERR, for some reason (which may be a clue to the fault)

[mikro]

I'm pretty sure the data cache is disabled by default. Even 16 MHz hasn't been set at this point. The fact that content of 0x00e00006 is fetched as well is quite confusing but this is what is supposed to happen on OK Falcon.

0x2711 is "move.l (a1), (a3)-" which is nowhere to be found in TOS disassembly.

[dml]

0x2711 is "move.l (a1), (a3)-" which is nowhere to be found in TOS disassembly.

I suppose $2700|CC would be the last thing pushed by an exception, not the first - so it probably is an instruction, or the result of the move/read itself (?)

Knowing the address would help but that's not going to be easy to track both at once. :/

[mikro]

Knowing the address would help but that's not going to be easy to track both at once. :/

Why not? /AS toggling is pretty deterministic, otherwise I wouldn't be able to scope 16 data lines one by one. I can do the same with address lines but oh boy, I really do now want to do that. :D

I'll check the working Falcon and if all signals look better there I will then decide whether I'll just go with the Mighty Sonic card or scope all the 24 address lines. Using the MS32 has its risks (unknown origin of the fault; very likely it was this card which was inserted wrongly....) but it can magically fix everything, too.

[dml]

Using the MS32 has its risks (unknown origin of the fault; very likely it was this card which was inserted wrongly....) but it can magically fix everything, too.

Maybe check for unexpected shorts-to-VCC on the MS connector on its own, before you let it near your new VIDEL.

Good luck.

[dml]

I forgot to ask - did you try checking the video out signal since you swapped VIDEL? Especially the RGB out - you should be seeing *something* by now if the CPU is able to fetch data at all, so should the VIDEL, unless COMBEL is not signalling to do so.

You should at least get a VSYNC or something... could provide some more clues.

[mikro]

I forgot to ask - did you try checking the video out signal since you swapped VIDEL?

Yes, that was covered by "We verified that DE is active (15.6 kHz)" ... I don't have an RGB monitor in my office but I'm pretty sure Videl outputs something, VGA monitor outputs the typical "out of sync" message so I don't think that needs to be further checked.

Btw, a "fun" side story: I was preparing the working falcon for some measurements. Suddenly, while being in the diag cart menu, I saw this:

rsod.jpg

and after reset, nothing, not even Videl output. Since I wasn't doing anything "live" (manipulating with the probes etc) my heart stopped for a second -- another dead Videl?!?!

Fortunately, now armed with knowledge about Videl's DE quirks (not there if only ROM but not RAM is fitted), I immediately started to suspect the RAM card. Fortunately I had another one, replaced... it worked until the moment I decided to knock on it a little, just to be sure. Of course it went back to this red screen and scary errors. 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.