DFB1r4 design discussion thread

[exxos]

For example, does anyone know how the COMBEL works? Will it assert BERR after 100 AS cycles even if it's already asserted XDTACK? Would this be the expected behaviour if XDTACK were being inadvertently driven high throughout?

I would assume it behaves similar to the ST GLUE. That if a address is on the bus, and nothing responds to DTACK, it will issue BERR about 100 clocks later. Which I can only assume can happen with a invalid address on the bus.

Are you totally sure you are driving DTACK as a tri-state output ?

[Badwolf]

For example, does anyone know how the COMBEL works? Will it assert BERR after 100 AS cycles even if it's already asserted XDTACK? Would this be the expected behaviour if XDTACK were being inadvertently driven high throughout?

I would assume it behaves similar to the ST GLUE. That if a address is on the bus, and nothing responds to DTACK, it will issue BERR about 100 clocks later. Which I can only assume can happen with a invalid address on the bus.

i was under the impression COMBEL drives XDTACK itself as it's both GLUE and MMU, in effect?

Are you totally sure you are driving DTACK as a tri-state output ?

My XDTACK connection is set as input only (until I enable the flash writing anyway), but I'm wondering if it's being driven high either by a short or it could just be a dodgy pin (have had that on these CPLDs).

I'll get the scope on it later. If it's 3V3, it's being driven. If it's 5V it could be a short or just genuinely never being asserted. I could then measure it out of the machine and finally I could cut the trace *then* probe the pin.

I could also fake my own DTACK and see if the data is actually being put on the bus.

Hopefully will get to the bottom of it. :|

BW

[exxos]

[quote=Badwolf post_id=70281 time=1631617800 user_id=797]
i was under the impression COMBEL drives XDTACK itself as it's both GLUE and MMU, in effect?
[quote]

Yeah it drives DTACK, but if your board is driving high for some reason..




Good plan.



Data should be on the bus pretty much straight after AS30 goes low. If its all 1's then you are in invalid address space which would be why you would not get DTACK from combel.

If however you get some zeros, then something is decoding that address, and that something should then issue DTACK.

I don't think you mentioned the reset signal. I assume you are waiting for reset to go high then do the BG stuff..

Have you also checked you are not inadvertently issuing a interrupt or something daft like that ?

[exxos]

i was under the impression COMBEL drives XDTACK itself as it's both GLUE and MMU, in effect?

Yeah it drives DTACK, but if your board is driving high for some reason..

I'll get the scope on it later. If it's 3V3, it's being driven. If it's 5V it could be a short or just genuinely never being asserted. I could then measure it out of the machine and finally I could cut the trace *then* probe the pin.

Good plan.

I could also fake my own DTACK and see if the data is actually being put on the bus.

Data should be on the bus pretty much straight after AS30 goes low. If its all 1's then you are in invalid address space which would be why you would not get DTACK from combel.

If however you get some zeros, then something is decoding that address, and that something should then issue DTACK.

I don't think you mentioned the reset signal. I assume you are waiting for reset to go high then do the BG stuff..

Have you also checked you are not inadvertently issuing a interrupt or something daft like that ?

[Badwolf]

i was under the impression COMBEL drives XDTACK itself as it's both GLUE and MMU, in effect?

Yeah it drives DTACK, but if your board is driving high for some reason..

Yeah, that was my guess -- if Combel just counts to 100 and then says bus error ignoring if it's tried to issue a DTACK already, then a stuck high line could fit the bill.

I could also fake my own DTACK and see if the data is actually being put on the bus.

Data should be on the bus pretty much straight after AS30 goes low. If its all 1's then you are in invalid address space which would be why you would not get DTACK from combel.

If however you get some zeros, then something is decoding that address, and that something should then issue DTACK.

Mmm. So I've a number of ways to test the stuck DTACK theory, then. Grand.

I don't think you mentioned the reset signal. I assume you are waiting for reset to go high then do the BG stuff..

Yes, this is all after reset and the bus arbitration dance is done. I don't think that'd work if reset were still asserted.

Have you also checked you are not inadvertently issuing a interrupt or something daft like that ?

Hmm. The processor wouldn't be concerning itself with the IPL lines at that point, I don't think, but perhaps something on the motherboard would react to the two external interrupt lines? Not sure -- I would think they'd just translate back to IPL anyway. I can probe them, though.

Cheers,

BW

[exxos]

Hmm. The processor wouldn't be concerning itself with the IPL lines at that point, I don't think, but perhaps something on the motherboard would react to the two external interrupt lines? Not sure -- I would think they'd just translate back to IPL anyway. I can probe them, though.

If theory should not happen but after all the crazy sh*t I have seen over the years :lol: I know you can get the processor / system in a odd state if you issue BG without BR for example. Don't remember exactly, But I remember having a odd issue like this with my booster and the ST GLUE.

As another thought, have you thought about using your board as a simple monitor / mirror system. IE, just get it to decode the ROM address and issue DTACK (isolated from the system DTACK) then measure both DTACK's on your scope and see if they both match.

[Badwolf]

As another thought, have you thought about using your board as a simple monitor / mirror system. IE, just get it to decode the ROM address and issue DTACK (isolated from the system DTACK) then measure both DTACK's on your scope and see if they both match.

Not quite following you on that one, I'm afraid. Can you run that past me again?

Ta,

BW.

[exxos]

Not quite following you on that one, I'm afraid. Can you run that past me again?

Have your Falcon running basically as a stock machine, but also have your booster board plugged in (without CPU even). then get your booster to decode the full ROM range and issue DTACK on a spare IO pin (not connected to system DTACK).

Then this spare IO pin will issue DTACK low on any ROM address on your scope. But also measure the actual Falcon side DTACK on your second scope channel. In fact measuring the motherboard ROM_CE probably be easier than DTACK..

So what will happen is, you have basically just a ROM decoder going on in your PLD, and you compare your "ROM DTACK" IO pin, with ROM_CE on the Falcon MB.

So what I'm saying is, your booster "ROM DTACK" should also match the ROM_CE Pulses on the motherboard ROM.. We can pretty much assume system DTACK will follow ROM_CE, but it is easier to just use ROM_CE for easy comparison with the ROM decoding in your PLD.

Being that this will check a lot of the address lines and your internal DTACK generating code. Obviously both signals should match perfectly. If there is a iffy address pin or something, then "ROM DTACK" on your PLD, will not always match ROM_CE on the Falcon ROM.

[Badwolf]

Being that this will check a lot of the address lines and your internal DTACK generating code. Obviously both signals should match perfectly. If there is a iffy address pin or something, then "ROM DTACK" on your PLD, will not always match ROM_CE on the Falcon ROM.

Aha, I see what you mean -- as a sanity check on address line integrity.

If I can figure out a good way to probe the XROM2 line, then yes that's feasible. I could do the same with the cartridge port (XROM3 and XROM4) trivially enough, too.

BW

[Badwolf]

Spent most of last evening trying to sort out insurance for my lad who's just passed his driving test. Not fun.

So I only had about half an hour to run through some tests.

* XDTACK line is at 5V throughout, suggesting it's not being held high by the CPLD (3V3)
* No short to 5V on the XDTACK pin

However when trying to implement the decode logic discussed above, I inadvertently built for the XC95144 instead of the 288 and by random chance flashing that firmware has locked the CPLD (this error https://www.exxosforum.co.uk/forum/viewt ... 44&p=43436).

Now I do have Impact and I can read the JTAG chain and all the rest of it, but I've *never* got any write operations to work in it. Erasing whilst clearing the write lock is no exception. It just hangs.

So now it's bricked. Bah. :pullhair:

I think I'll be building up another bare bones debug board. Just CPLD, regulator & their associated caps. Fingers crossed it's just a cursed board.

BW