[Video] Broken Falcon030 Motherboard

[Badwolf]

Happy Friday folks!

Some time ago I bought a bit of a battered Falcon motherboard from @Acsi in the hope of being able to get it running, but to have some spare parts perhaps for my main board if by DFB1 development killed it.

Well, four years down the line, I've decided I need the box it's in. So I'd better have a look at it.





In part one here, I do a bit of an inspection and clean before moving on to some soldering fix-ups and finally some electrical testing.

When will the magic smoke make an appearance?

Cheers,

BW

[dml]

I'm already spamming the comment stream with F030 fixage notes I'll move it here...

The nasty splodge on the back side of the CPU I think was someone flooding the CPU pins with flux and then applying hot air for too long while trying to get the CPU off - which baked and lifted those pads but also caused the flux to soak through the vias and pooled under the board. So a giant flux mess

BTW the pads coming off so easily is another clue the resin holding them got baked for too long with hot air. Any heat now just floats them off. You were probably lucky to lose only 4 of them.

[mikro]

From what I have seen so far - definitely a Phantom/Nemesis-like booster and yes, those caps are new, definitely not original. Same about the lower pin headers of the expansion slot and memory card slot, not original.

WTF was happening with that machine...

EDIT: here's a few details about the board: viewtopic.php?p=63905#p63905

[Badwolf]

Spoilers below as I've working on the next part of the video and want to discuss how I've got on.

Show Spoiler

I've dug out an old rev4 DFB1 card and have strapped it up to run at stock motherboard speed and without using the flash ROM. Basically it's just a surrogate for the onboard CPU.

In order to get the bus arbitration (and GAL mode) dance to work, I've tied the BG30 pin on U68 to ground. Effectively every time something asks for the bus, it's already granted. This may have to be returned to if I get things working as it may not work nicely when the blitter and SDMA get involved, but should suffice for running the diagnostic cart.

Now, with the diagnostic card in place I can see AS activity after a reset, Sometimes it's very brief -- a few cycles, mostly it's a few milliseconds worth, sometimes it's free running. When execution stops I can't see any obvious problem like a still-asserted AS line or a BERR occurring, but a lot of the actual CPU pins are now hidden from probing, so it could be internal to the expansion board, I suppose.

When it's got to the free-running stage I can see ROM4 strobing suggseting the ROM has booted far enough to do the magic number detection and then moved on to executing code on the cartridge.

Nothing appears on the VGA output nor on the serial line, however. I don't have a floppy attached, but the keyboard drive indicator light doesn't pulse.

Given the above (it's got that far) I don't immediately suspect a databus issue, although the start-stop nature of the execution does seem to suggest to me something's getting duff data and is either lucky in that it happens to hit on something that is valid to execute or it errors and halts.

What's are the most likely things to be looking for given these circumstances, do we think?

I can eventually hook up a full logic analyser to the address and/or data bus, but I'll welcome suggestions of things to target immediately.

According to Acsi, this used to have a HS-32 (bus accelerator?) inside it, so I'll check the ACIA clocks, but would absent ACIAs exhibit this behaviour?


Cheers,

BW

[Badwolf]

From what I have seen so far - definitely a Phantom/Nemesis-like booster and yes, those caps are new, definitely not original. Same about the lower pin headers of the expansion slot and memory card slot, not original.

WTF was happening with that machine...

EDIT: here's a few details about the board: viewtopic.php?p=63905#p63905

Cheers. Yes it was meant to have had an HS-32, but I wonder if that was really an HS-40 with a 20MHz bus clock?

I'm still not sure about those lower expansion and memory headers. Why would they be changed? Why are they caked in flux like the other rework areas? Why both? Is it possible early boards had lower headers at the front to slope the expansions down with the keyboard a bit?

BW

[dml]

Didn't you mention the STRam board was faulty? Or is it known that it would get much further along before problems? If it is already looking safe to use a good STRam board it might be worth it to remove another variable.

BTW I don't think a Falcon will boot with a bad DSP. You may get a white screen but TOS will halt somewhere early trying to initialise it.

[Badwolf]

I'm already spamming the comment stream with F030 fixage notes I'll move it here...

Cheers very much! I'll need a collective effort on this one, I'm sure.

BTW the pads coming off so easily is another clue the resin holding them got baked for too long with hot air. Any heat now just floats them off. You were probably lucky to lose only 4 of them.

I did the same when I removed a broken FPU socket some years back. Fortunaely all my pad losses were NCs.

In this case, on video, you could see a few pads missing or floating before I got there. In real life it looked like I'd massacred the poor thing right before my eyes.

BW

[Badwolf]

Didn't you mention the STRam board was faulty? Or is it known that it would get much further along before problems? If it is already looking safe to use a good STRam board it might be worth it to remove another variable.

Good point. I should try this board in my working Falcon (safer that way around).

BTW I don't think a Falcon will boot with a bad DSP. You may get a white screen but TOS will halt somewhere early trying to initialise it.

I'm hoping the diag cart will not have such problems, but I may look to try to get a custom EmuTOS or DiagROM in there as well.

I have an old cartridge flash adapter I might break out for specialist software tests. I was thinking about getting the DFB1 to expose the LEDs to registers and providing a simple bit of code to flash them.

BW

[dml]

I'm hoping the diag cart will not have such problems, but I may look to try to get a custom EmuTOS or DiagROM in there as well.

I think that will be ok yes. The diag cart won't touch the DSP unless you use the test.

I have an old cartridge flash adapter I might break out for specialist software tests. I was thinking about getting the DFB1 to expose the LEDs to registers and providing a simple bit of code to flash them.

That would be handy!

[dml]

You might also be tempted to take all 5 GALs out of the dead board and try them in your working machine. I don't think its very risky and if one is faulty it could keep you guessing & tracing around for a good while.