Falcon error: T4 Video Counter in Memory Controller

[Badwolf]

Lift the gal pin out out of the socket, and see if it tracks then?

Good point: I've already done that test to some degree: I lifted the pin on the old GAL and jumpered XBERR to EBERR and I got a boot of sorts: the screen came up and the cartridge initialised, but interestingly all the text was in two columns on the left of the screen!

I didn't look any further at that as that implied a GAL fault to me, but it does then start to look more like an upstream issue.

Might be worth looking at the gal code as I think it was all a bit if a mixed bag of chaos of what's driving what.

Yep, I foresee more confused staring at CUPL code in my immediate future :o)

BW

[Badwolf]

Hurrah! As of last evening the Falcon was flying again.

All the logic analyser to-ing and fro-ing and burning a new GAL for U63 was a bit overkill in the end although the missing EBERR picked up by the LA was the key clue in the end.

100 internet points if anyone can guess what it was, though!

BW

[exxos]

:shrug:

Bad socket ?

[dml]

Hurrah! As of last evening the Falcon was flying again.

\o/

100 internet points if anyone can guess what it was, though!

Oooh, points!

...

.....logic wookies?

........

I'm out of ideas now - what was it?

[Badwolf]

Bad socket ?

*non commital but generally positive sounds whilst scratching chin*

.....logic wookies?

Very close...

Any more for any more?

BW

[dml]

Any more for any more?

DFB1 prototype flashed with STE536 firmware? :p

GAL in backwards?

Just tell me when to stop.

[exxos]

DFB1 prototype flashed with STE536 firmware? :p

That would be interesting fireworks :lol:

Maybe broken trace to the GAL ?

[Badwolf]

Ooo, getting close!

There are about a million contributing signals to first enabling the EBERR output on U63 and then assering it as Exxos alluded to earlier in the thread. Some originate within U63 itself, others are piped from U68.

U63 appeared to have signals I'd expect on most of its pins, but EDSP coming from U68 didn't make sense, so I shifted my focus there.

U68 is an even deeper morass of dependencies but the mysterious EDSP has a dependency on the even more mysterious 'AXDSP'. And that started out toggling away happily but then ending up an an intermediate ~2V state.

Contention?

AXDSP is an input coming from U44, right over on the other side of the board with its own set of extensive dependencies. It appears to be a partial decode of the DSP registers. But how can it end up contended? It doesn't seem to go anywhere else.

So I removed U44 to see if it remained contended. It didn't.

So I replaced U44.







Problem solved, booting like a trooper!

?? !??!!?! !?!! :cussing: :mad: :WTF:

So bad seating? How would that end up with 2V on the line when removing it didn't? How did it work some of the time? Some other issue? Perhaps U44 was losing its ground and things were getting stuck in a latch up situation? Why after 700ms?

*gibber*

BW

[exxos]

:dizzy:

Welcome to the world of the Atari I guess :lol:

[Maximilian]

You Atari guys have all the fun :lol:

Nice find!!