[Video] Broken Falcon030 Motherboard

[Badwolf]

For me it matters whether it is a long or short push of the button.

This does appear to be the same effect: short push OK, long push, errant pulses.

My initial analysis suggests to me that basically the circuit is trying to ensure a minimum reset pulse width after a button push. That seems to be around 300-400ms.

A push shorter than that will keep RESET (and HALT) asserted until C1 is charged past the threshold voltage and then RESET can be released. That's the 300-400ms period.

A push longer that that, however, allows C1 to be charged past that threshold already when the button is released. At that point the deassertion of the output can happen instantly.

BUT that means any bouncyness or scratchyness in the reset button that gets past the open-collector NOT gates at the beginning of the circuit will be transmitted through to the RESET line until C1 has discharged sufficiently to break the cycle again. And I think that's what we're seeing here.

I'm not 100% sure what C7 brings to the party. On the face of it all it appears to do is tax the upstream NOT gates' current sinking ability. It seems to fill and drain too quickly to have much influence over anything else.

I don't know enough about 555s to see if there's a quick way to only start filling C1 when the reset switch is relased (changing its behavior to assert ~300ms after reset is relased), but for now I'll put that down as a bad job and move on to what that RAM test is telling us.

:lol: ras/cas issues?

Good shout. I don't know much about the Falcon's ST-RAM interface, so I'd better get learning.

From what I can tell about the diagnostic cart's output, however, each of those lines represents a bit failure when writing zeros to a single address, namely 0x8. Since the memory connector is 32 bits wide I'm guessing each one corrsponds to a data line on the memory connector (athough that's obviously not true on the ST range where it's presented the same way, so I may be barking up the wrong tree).

The spectacular number of ones in that capture (which came from a known working card) implies to me that it's likely something centralised rather than a bad pin contact on the header or a pair of shorted contacts. RAS and CAS would certainly fit that bill, so I'll be taking a look at those when I can. Thanks.

There don't appear to be many other candidates to investigate on that path. VCC, Ground and MADDR, I suppose. MDATA seems to be a direct connection without buffering or filtering to VIDEL.

One nota bene, I did also get a couple of I2 RAM Disturbance messages (0x8 and 0x67E, IIRC). The fact it's only two is interesting, though, as the service manual seems to imply there should be 2040 tests done at the I2 point.

Also I should note that it takes a lot of resets to get any output on the serial port. I was actually testing the the reset pulses when I changed windows and noticed I'd generated something there. Again, that to me suggests the RAM is perhaps required to get to the screen output point and is obviously not *completely* toast, although that may be wishful thinking.

Not having the 500kHz clock to the keyboard ACIA definitely caused my Falcon to fail to boot when I tried to fit a Nemesis upgrade last year

Thanks Steve. I've not got around to checking those yet, but that one and the NVRAM are in my mind.

BW

[Badwolf]

I had a good probe of the RAS and CAS lines and various other control and data lines on the memory board last night and could see little wrong.

Throughout all my tests I never got any output on the serial port again. Curious.

That led me to think about contacts on the expansion port. Or some other intermittent signal problem. I'm not sure how that would explain so many memory faults, but it's something to try.

So did a bit of contact cleaning and seating-reseating and suddenly I got a good picture on RGB and output on the serial with a new message:

Code: Select all

Checking FPU...
EF FPU not found
Initializing PSG...
EB Bus error Access Address: FF8936 Program Counter: 0E03A6

EB Bus error Access Address: FF8936 Program Counter: 0E03A6

This was repeatable for a few resets until I moved the board again. Possible intermittent trace failure somewhere?

Anyway, I don't know about the program counter being in RAM, but the address is something related to the Falcon's sound hardware, from what I can tell.

Can anyone tell me where this register 'lives' and what would be issuing DTACK (or equivalent) for it? I'm minded of all that mangling over by the DSP, but I do wonder if this is emanating from elsewhere.

Cheers,

BW

[dml]

FF8936 is the DMA recording control register (record channels select) for the crossbar / SDMA config.

[stephen_usher]

By expansion port do you mean the one where the DFB1X plugs in?

I seem to remember that it has shorter pins than normal on one of the pin headers... Possibly not making a good connection there?

[Badwolf]

FF8936 is the DMA recording control register (record channels select) for the crossbar / SDMA config.

Aha, so it's an SDMA register? I see SDMA has its own EDTACK line so that would make sense. Thanks.

By expansion port do you mean the one where the DFB1X plugs in?
I seem to remember that it has shorter pins than normal on one of the pin headers... Possibly not making a good connection there?

Yes. Good point. It's all the data lines on that 'short' header. The memory board has the same short pins on the small connector and that's RAS/CAS too.

Mmm.

BW

[Badwolf]

Armed with the knowledge of possible SDMA knack, I tried a bit of a cleanup and some board manipulation last night.

Applying a bit of pressure to the top of the SDMA chip and...

bsool.png

The fabulous blue screen of (occasional) life!

Now sadly, it can't recognise a keyboard and the serial interface doesn't let me perform many tests, so little was gained there, but I reckon it's time for a bit of a poke around and reflow of the SDMA area.

I couldn't see a chip select line for SDMA, but I can see all the address lines are exposed so potentially it decodes its own address range? Does anyone know for sure?

The keyboad ACIA appears to have its clocks -- which was an initial concern -- but like I say nothing's recognised ATM. I wonder if that corner of the board has issues. We've seen the mangled DSP. The rework going on around one of the logic chips over there and now SDMA and the keyboard aren't working properly. Some potential board problem over that way?

Cheers,

BW

[dml]

The fabulous blue screen of (occasional) life!

\o/

Yet another case of chips desoldering themselves through incremental crustyness!

Now sadly, it can't recognise a keyboard and the serial interface doesn't let me perform many tests, so little was gained there, but I reckon it's time for a bit of a poke around and reflow of the SDMA area.

2 steps forward, 1.75 back...

I couldn't see a chip select line for SDMA, but I can see all the address lines are exposed so potentially it decodes its own address range? Does anyone know for sure?

I think it is supposed to be a busmaster for its main duties shoving data around between other chips. How it recognises a register write though - not sure. Maybe it does snoop it.

I can't really look just now but if there is no CS equivalent then I guess has to be watching the range as you say. Or they used a very obscure name for the CS there.

The keyboad ACIA appears to have its clocks -- which was an initial concern -- but like I say nothing's recognised ATM. I wonder if that corner of the board has issues. We've seen the mangled DSP. The rework going on around one of the logic chips over there and now SDMA and the keyboard aren't working properly. Some potential board problem over that way?

Good luck exploring that zone for more clues...

[Badwolf]

SDMA reflowed and, in that area, I found a nasty solder dag beneath U40 which I think was causing a few problems.

The DSP is still failing tests, but one pin is completely floating, so that's not unexpected. I then tried a new experimental hack to the bus grant system...

desktop.png

Progress continues slowly!

BW

[peters]

That looks like good progress.

[alexh]

I'd say that the chances of this Falcon flying again just got a lot better.

I wonder how it got into such a bad state?