How to diagnose dead Videl?

[exxos]

I would continuity check all addess lines to the ROM. Assuming combel does ROM decoding then check address lines there also.

You don't say what address lines you actually checked.. Maybe the CPU is trying to cycle for the first few addresses. But assuming combel does ROM decoding, its not decoding the ROM addresses correctly, hence ROM CE seems "late".

I suggest checking all addess pins on the CPU are all low when reset goes high. Next check the combel sees the same addresses, all low.

If combel sees all low addresses after reset but doesn't set ROM CE low. Then something is wrong with combel decoding.

[Badwolf]

Once AS goes low it will stay that way until a DSACK[x] or BERR is received*.

I suspect COMBEL is responsible for generating both for ROM accesses. Whilst I don't know for sure that it's COMBEL, I do know that the ROM itself doesn't assert any DSACK, so you should have no difference in AS, DTACK and BERR assertions whether the ROM or RAM is in or out.

AFAIK if COMBEL counts a sufficient number (64?) of clock cycles and AS is still asserted, it asserts BERR irrespective of the address asked for. I, again, don't know that for certain but haven't run across an address or FC[x] combination that it doesn't yet. I think it's a decent enough assumption for starters.

SO: I'd focus on measuring signals around COMBEL. Is it seeing AS? Is it asserting BERR or DSACK[1] and the CPU isn't seeing them? It could be something as simple as a trace break between the two chips.

BW

* Technically it could also be terminated on an STERM but this is not used on the Falcon and should be tied high. DSACK[1] is normally asserted by itself for all 16 bit accesses, but there's a GAL that handles DSACK[0] for the DSP, and I think the FPU might use both DSACKs. Either way, we're not seeing either being asserted, it seems.

[mikro]

I suspect COMBEL is responsible for generating both for ROM accesses. Whilst I don't know for sure that it's COMBEL, I do know that the ROM itself doesn't assert any DSACK, so you should have no difference in AS, DTACK and BERR assertions whether the ROM or RAM is in or out.

AFAIK if COMBEL counts a sufficient number (64?) of clock cycles and AS is still asserted, it asserts BERR irrespective of the address asked for. I, again, don't know that for certain but haven't run across an address or FC[x] combination that it doesn't yet. I think it's a decent enough assumption for starters.

SO: I'd focus on measuring signals around COMBEL. Is it seeing AS? Is it asserting BERR or DSACK[1] and the CPU isn't seeing them? It could be something as simple as a trace break between the two chips.

Mate, you are reading my mind. I was just typing exactly this kind of questions and here you go, answering them before me!

This is exactly what I needed to know, on it.

EDIT: As I'm thinking about it, this could also explain the Videl mystery -- as Videl CS goes also from the Combel.

[Badwolf]

EDIT: As I'm thinking about it, this could also explain the Videl mystery -- as Videl CS goes also from the Combel.

True, but if COMBEL were completely toast I don't think you'd be seeing ROM4 activate -- which I think you were seeing, weren't you?

[Sorry, I was away for a fair chunk of this thread and haven't fully caught up]

BW

[mikro]

@Badwolf nope, ROM4 is also dead. So no cartridge activity.

[Badwolf]

@Badwolf nope, ROM4 is also dead. So no cartridge activity.

Ah, apologies, I misremembered the line: I meant the one to the main PLCC. XROM2. That should go low with the first AS assertion.

Reading back I can't see that's actually been confirmed asserting either, so it *could* be an unwell COMBEL.

BW

[dml]

@Badwolf nope, ROM4 is also dead. So no cartridge activity.

Do you see any indication of BERR between the CPU/COMBEL or HALT from the CPU - or the BR bus request being busy?

There are a few lines involved with bus arbitration BR/BG/BGACK etc. but there might be a clue here if one of the chips is hogging the bus all the time. e.g. if an IC has requested the bus BR but didn't get BG, or if BG toggles but no BGACK... it's something which could be followed (probably only a few cycles deep before a dead end) and might provide a clue. Maybe @Badwolf or @exxos could provide a more precise debugging sequence to follow for this one. I would probably start by just seeing if any of them toggle and in what order, then figure out if it makes sense and/or at what step it gets stuck.

The 030 should be busmaster most of the time but COMBEL might be first as a special case (not sure but you can confirm with working machine)

[Badwolf]

The 030 should be busmaster most of the time but COMBEL might be first as a special case (not sure but you can confirm with working machine)

COMBEL should issue the BERR after too many clock cycles with an unacknowledged AS irrespective of what's asserting AS, I believe.

So, to me, the lack of activity on DSACK[1] and BERR is the first thing to have a look at. Are they not asserted as AS isn't seen by COMBEL? are they asserted but not being seen by the CPU? Are they not asserted despite AS and CLK (which is generated by the COMBEL, IIRC) being present at COMBEL?

First two would point to traces. Last one could be a dead COMBEL or (both?) lines shorted high.

BW

[exxos]

The 030 should be busmaster most of the time but COMBEL might be first as a special case (not sure but you can confirm with working machine)

@mikro needs to verify the address bus is sound before doing anything else. No use worrying about any other signals as they are somewhat relevant at this point. But of course BR/BG/BGACK should all be high after reset else it could give weird results.

Though I feel I am repeating myself over and over now.. No use doing anything until the address bus is checked properly..

Address bus to ROM, Combel , CPU check first. Need to check all address zeros after reset. Then put the ROM back in , then measure the first bus cycle after reset to make sure the ROM contents is been seen at the CPU as expected on the data bus, ROM CE should go low with the first AS low.. If verified good, then look at DTACK/BERR etc as they terminate the cycle. If the address is wrong, then BERR will trigger as nothing will be issuing DTACK on a bad address (assuming nothing else is at that address and triggering DTACK).

[mikro]

@mikro needs to verify the address bus is sound before doing anything else. No use worrying about any other signals as they are somewhat relevant at this point. But of course BR/BG/BGACK should all be high after reset else it could give weird results.

Mikro will do all of the things tomorrow, thank you all for great hints. Just to quickly reply to the easiest stuff to @dml and @Badwolf:

- /HALT and /BERR is never LOW (measured on the EXP connector). I have to check the Combel side to confirm this, too

- /BR/BG/BGACK are also never LOW - I compared this to the good Falcon, at least without ROM and RAM, nobody is asking to take over from the 030 so this should be good

- /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)