How to diagnose dead Videl?

[mikro]

Oookay. So I have measured all data lines and verified it against expected values nicely put together by @sdisla:

Code: Select all

D0 0000
D1 1000
D2 1100
D3 1000

D4 0001
D5 1011
D6 0010
D7 0010

D8 0000
D9 0000
D10 0100
D11 0000

D12 0000
D13 1000
D14 1000
D15 0000

Assorting them and converting to hex.

Code: Select all

0110 0000 0010 1110  ===> 602E
0000 0100 0000 0100 ===> 0404
0000 0000 1110 0000 ===> 00E0
0000 0000 0011 0000 ===> 0030 

In his case address and data lines were also fine but ironically, one of the GALs, U62, was wrong. But since I swapped all GALs from my working Falcon...

I guess I could measure the next four words and then next and so on (I need to actually google how to set a trigger on a later assertion ;-)) on the scope until I hit a wall. Maybe I was right with my assumption that the first access to memory makes things go wrong?

Btw, why it is even reading code that far? I could understand that CPU asks for one long ($602e0404) but how it happens that it reads two, i.e. the second which isn't executed at all? Is it because of the fetch - decode - execute pipeline, so CPU is about to execute the BRA but CPU is in the meantime hungry for more fetches?

[Badwolf]

Assorting them and converting to hex.

Code: Select all

0110 0000 0010 1110  ===> 602E
0000 0100 0000 0100 ===> 0404
0000 0000 1110 0000 ===> 00E0
0000 0000 0011 0000 ===> 0030 

In his case address and data lines were also fine but ironically, one of the GALs, U62, was wrong. But since I swapped all GALs from my working Falcon...

I guess I could measure the next four words and then next and so on (I need to actually google how to set a trigger on a later assertion ;-)) on the scope until I hit a wall. Maybe I was right with my assumption that the first access to memory makes things go wrong?

Looks good so far.

I don't think you touch RAM before ROM4 should be asserted.

Looking at your disassemby from earlier:-

Code: Select all

00000030 : 46fc 2700      MOVE.W   #$2700,SR				<- internal to the CPU
00000034 : 3038 8006      MOVE.W   $00008006,D0				<- reading from Falcon's monitor and bus control registers
00000038 : 4e70                RESET     				<- should be easily measurable
0000003a : 3038 8006      MOVE.W   $00008006,D0 			<- reading from Falcon's monitor and bus control registers again
0000003e : 31fc 0007 8940 MOVE.W   #$0007,$00008940 			<- setting GPIO data direction to out (?)
00000044 : 0cb9 fa52 235f 00fa 0000 CMPI.L   #$FA52235F,$00fa0000	<- check for magic number on the cartridge by reading from the ROM4 range

So one thing is easily checkable. Do you see RESET asserted after the first few (ten or eleven?) AS assertions?

You've already seen ROM4 fail to go low so you know somehing's wrong between hither and thither. If the software (CPU-driven) reset is asserting, you can, concentrate on reading the bus signals immediately after it. There should be that 16 bit read from the ff8006 register, the 16 bit write to the ff8940 register and then the attempt to access the cartridge. You should be able to map out where things go awry.

If you *don't* see the CPU-initiated reset, then continue mapping after the first four AS assertions up until you ought to be reading E00038 & see if you can spot where it departs from your expectations.

If, for some reason the read from FA0000 is instructed but you don't see ROM4, then it's trace checking time & possible COMBEL suspicion again.

BW

[mikro]

I don't think you touch RAM before ROM4 should be asserted.

Ah, right. I was confused by that "MOVE.W #$0007,$00008940" but that's in fact "MOVE.W #$0007,$ffff8940", isn't it (same for "MOVE.W $00008006,D0"). What kind of disassembly that was. :-O

So one thing is easily checkable. Do you see RESET asserted after the first few (ten or eleven?) AS assertions?

True, I almost forgot about the reset. OK, let me check how can I show more assertions on the scope and I'll gather more evidence. Thanks!

[Badwolf]

I don't think you touch RAM before ROM4 should be asserted.

Ah, right. I was confused by that "MOVE.W #$0007,$00008940" but that's in fact "MOVE.W #$0007,$ffff8940", isn't it. What kind of disassembly that was. :-O

I'm an assembly n00b and it just confuses the hell out of me. When is a move.w not a move.w? :shock: The only way I can tell it's a 16 bit sign-extended move.w rather than a full 32 bit address move.w is by actually reading the hex next to it!

BW

[mikro]

Oh crap. Most likely I found the reason why the CPU doesn't do what it is supposed to do. Since I didn't see any /RESET I inspected further down the bitstream and then it hit me. Look at this D5 line for instance, it should be 1011:

d5.jpg

And at the first sight it is, right? However while @dml or @Badwolf or @exxos would see the problem in the next second, it took me a full day to realise. :D The voltage level is too low!

Interestingly, it doesn't apply to *all* data lines, just a few of them (I haven't re-measured everything yet to get a list).

So ... what is the quickest way to determine who's dragging those levels down (once I have a list of lines to which this applies to).

[exxos]

Take the ROM out.. Hold the reset button in and measure if you see 5v then.. Check the pullups on the bus as well.

[mikro]

I'm pretty confused by all the measurements I did.

First I tried to check resistance between VCC (EXP#30) and all the data and address pins on the EXP connectors (similarly as hinted here: viewtopic.php?p=29461#p29461):

D0 - D7: 9.5K
D8 - D15: 8.5K

Hmm. The good Falcon had all of those at about 10K. And when I got back to the bad Falcon, and specifically D8-D15 were also 10K. So perhaps this is OK (?)

A1: 2.3K
A2 - A5: 2.8K
A6 - A7: 3.2K
A8 - A9: 2.8K
A10: 0.8K (!)
A11: 2.8K
A12 - A23: 3.2K

Again, when I went to check this with the good Falcon, I could see the values are supposed to be around 2.8K and when I re-measured the bad Falcon I could see e.g. A1 being close to 2.8K as well so perhaps that's good but that A10 ... that stayed at 0.8K no matter what (and of course it isn't 0.8K on the good Falcon). So that's something I guess?

Then the ill-fated reset circuit. Its various red flags were hidden by all that /AS debugging. I re-measured everything again without ROM/RAM and for my final measurement I even used the same PSU because the level of my paranoia was raising after every measurement (all values are Uavg/Urms):

U2#1 - good: 5.01V - bad: 4.93V
U1#8 - good: 5.08V - bad: 5.08V
U1#3 - good: 4.4V - bad: 4.56V
U11#1 - good: 4.4V - bad: 4.56V
U11#2 - good: 5.08V - bad: 3.83V (!)
EXP#17 - same as U11#2

reset.jpg

So we see that the PSU is delivering stable 5.08V to LM555 however slightly less on U2's pin 1 (perhaps due to R2?) but so far so good. Then LM555 outputs about 0.5V less on both Falcons only to find out that the 74LS06 outputs the original 5.08V on the good Falcon and crippled 3.83V on the bad one!

What is even more confusing, I swear I saw that value going higher over time (to e.g. 4.4) and then back to 3.8V but I couldn't find any pattern in it. After that I re-soldered pins of U1 and U11 (as those had been swapped earlier) just to be sure and after that I could see the 3.83 all the time (maybe a coincidence).

So it seems like there are still two separate faults:

- the suspicious 0.8K between VCC and A10
- the suspiciously low voltage coming out of U11

As I replaced U11 a few months ago perhaps we can rule out the possibility that it's broken? Do you see something else in the schematics which could drag U11's pin 2 down so much?

[exxos]

Indeed A10 seems wrong. Locate the resistor pack where A10 goes, carefully remove it from the motherboard and test its resistances to make sure its not broken.

But for the reset line, have you check resistance on the XHALT XRESET lines from the LS06 will need a pullup to 5V as the LS06 is open collector.

You can probably rule out all the reset circuit shenanigans if you just lift those two pins out of the socket then tie them to 5V via a 10K, then see if the reset circuit behaves.

But also how are you measuring the voltage, I assume with a scope ? Because if they are switching you will not get a proper voltage reading anyway..

[mikro]

But also how are you measuring the voltage, I assume with a scope ? Because if they are switching you will not get a proper voltage reading anyway..

Yes, with the scope. Is there a better method? I assumed that a multimeter would give me worse results.

Also, which two pins are you referring to? (just to be sure)

EDIT: XRESET and XHALT (against VCC) shows 1K and 1.2K on both good and bad Falcon.

[exxos]

Yes, with the scope. Is there a better method? I assumed that a multimeter would give me worse results.

Scope is the correct method for those tests.

Also, which two pins are you referring to? (just to be sure)

Pin 2 and 4.. of U11. XRESET and XHALT

If you get the correct voltages with the pins lifted and connect each to VCC via like 10K or 1K or something similar, then you know the problem is downstream...