Falcon error: T4 Video Counter in Memory Controller

[Badwolf]

IIRC running slowly is when the CPU doesn't see DTACK and it times out to complete the cycle with GLUE logic, whatever the Falcon version is.

Thanks. And yes, that's exactly what I think that was. I was seeing a lot of BERRs. I don't think COMBEL works the same way as GLUE, though. I don't *think* there's a straight 128 cycle timeout. I may be misremembering, but I think @ijor mentioned that COMBEL actively decodes addresses to assert BERR for.

Which might explain my next problem: execution stopping with an asserted AS. COMBEL may be interpreting an address as one it has no interest in and asserting neither DTACK nor BERR?

Hence the descent into logic analyser madness.

But if your having odd video corruption as well, maybe a couple lines iffy somewhere ? Maybe resolder the videl, cpu, combel ?

That looked to be a bit of a one off, but that video counter error persists.

I've done a partial reflow of COMBEL, I think a full reflow is on the cards. Videl I've yet to touch, but I don't think it's first in the crosshairs. I've no CPU to reflow, though!

BW

[exxos]

Which might explain my next problem: execution stopping with an asserted AS. COMBEL may be interpreting an address as one it has no interest in and asserting neither DTACK nor BERR?
...
That looked to be a bit of a one off, but that video counter error persists.

Possible common thing is address line error ? Maybe combel sees random wrong addresses causing the first problem , as combel drives signals to the videl, *might* also explain some weird video issues as well ?

Or maybe worse, address line from the CPU not connecting to the whole bus intermittently ? Assume you tried tests by pushing down on various points on the board and chips to see if you can localise some area which seems "sensitive" ?

[Badwolf]

Or maybe worse, address line from the CPU not connecting to the whole bus intermittently ? Assume you tried tests by pushing down on various points on the board and chips to see if you can localise some area which seems "sensitive" ?

Yeah. And nothing yet.

Address lines have been my main line of investigation, but everything buzzes out and obviously it was running pretty well at one point. That's why reflow is the next thing on my list. The address lines might be behaving perfectly everywhere apart from where they're needed -- at COMBEL.

I can hope, at least.

While I was looking into the IDE problem I actually was thinking more about data lines. Specifically the pull-ups. I theorised if the a data line were floating an IDE device may be detected where none existed. And often the low half the bus was returning 0xff, but not the high. Possible intermittent loss of VCC to a pull-up, I was thinking. But I couldn't find that and I can't see how that would fit with this symptom now either.

So address does seem more likely.

Unless something's stomping on the bus, of course. Hence the analyser coming out.

BW

[exxos]

Address lines have been my main line of investigation, but everything buzzes out and obviously it was running pretty well at one point. That's why reflow is the next thing on my list. The address lines might be behaving perfectly everywhere apart from where they're needed -- at COMBEL.

MB bus pullups tested they are connected to the bus ? May be worth checking resistance on a couple points across the MB in case there's more than 1 track spanning off from the pullups..

[Badwolf]

Address lines have been my main line of investigation, but everything buzzes out and obviously it was running pretty well at one point. That's why reflow is the next thing on my list. The address lines might be behaving perfectly everywhere apart from where they're needed -- at COMBEL.

MB bus pullups tested they are connected to the bus ? May be worth checking resistance on a couple points across the MB in case there's more than 1 track spanning off from the pullups..

In terms of the data lines, I've checked at the expansion connector (where the CPU lives) and the IDE header and things *seem* to be behaving. But if it's intermittent it must be on an order much faster than I could probe.

BW

[Badwolf]

Here's one of the snapshots I captured late last night. Running the diag cart. Everything appears to be going ahead normally until suddenly AS (B15 here) asserts and never terminates. This is after about 700ms so thousands of cycles down the line. Always around the same point, but not exactly.

The address on the bus is 0x0F3FC0 (marker C). We can see several accesses to 0x0F3Fxx ranges before (marker D), so what gives?

(if I had to hazard a guess without disassembling the code yet, it looks like the cart is copying something from the 0xfbxxxx range to RAM -- the lower 4 bytes are common)

I need to perhaps probe right at COMBEL to make sure the signal isn't being lost between it, the GALs and the expansion port.

BW

[ijor]

I may be misremembering, but I think @ijor mentioned that COMBEL actively decodes addresses to assert BERR for.

It was Christian who said that, not me. But yes, seems COMBEL asserts BERR pro actively in some cases.

[Badwolf]

I may be misremembering, but I think @ijor mentioned that COMBEL actively decodes addresses to assert BERR for.

It was Christian who said that, not me. But yes, seems COMBEL asserts BERR pro actively in some cases.

Aha, thanks for the correction!

In some cases, though? Does that mean the timeout is still there as well? That might then suggest perhaps COMBEL isn't seeing AS. Or it really is toast. :(

Cheers,

BW

EDIT: mind you, an intermittent AS connectivity fault wouldn't explain why it seems to survive around 700ms each time. Bah.

[ijor]

In some cases, though? Does that mean the timeout is still there as well? That might then suggest perhaps COMBEL isn't seeing AS. Or it really is toast. :(

I'm not sure, but yes, I would certainly expect that the timeout would still be there.

[dml]

I would guess that if it was working better early on but started deteriorating, it's probably not a faulty IC but some kind of connectivity problem, contact resistance or interference. It could even be on the DFB1 hybrid itself?

...unless an IC is getting hot somewhere of course, then it could degrade fairly quickly and permanently.

So what you are seeing is less likely to be a Combel internal fault, which might be good news?


Re the bus error timeouts - the Combel does decode certain ranges for instant buserror response and I think it also has the timeout behaviour as a backstop, probably for ranges which are not within the normal hardware register area.