exxos's DFB1 trials

[Badwolf]

So all other than the FPU mystery, is there anything you want me to specifically test while it is connected up ?

Nono, have a play with it. Have fun. The more out there the merrier.

If you find a bug you're in a good position to provide a report with oscilloscope traces. ;)

Not sure if there is a different firmware for with and without FPU ? I did quickly plug in one earlier and it crashed on the first FPU test. maybe it is not getting clock for DTACK is broken :shrug:

No different firmware. FPU works on my board and at least one other user I know. Steve had his working too, I think.

That 13 bomb failure is what I was seeing here too, although all the pins seemed to buzz out for me. I suspected the socket was a bit iffy (there's a bad pin around the DSACK[x] area which I've tried to repair [northwest of the socket]), but I wasn't able to track it down.

Could be clock, AS, DS, address lines, DSACK[x]. Couldn't find a problem with the scope, but pressing on the chip seemed to result in it no longer even being detected, which makes me think control lines rather than address.

Clock and DSACK[x] are fed from the CPLD, AS, DS and the two busses go directly from FPU to CPU.

BW.

[Badwolf]

Oddly it seems to have "died" somehow. Now it gets stuck exact same place...

Try with FASTRAM.PRG instead? (I really am not convinced by that version of MAPROM yet)

I don't have the "working" version of MAPROM to hand ATM. I thought I'd posted it on another thread, but can't find it now.

BW

[exxos]

Try with FASTRAM.PRG instead? (I really am not convinced by that version of MAPROM yet)

That booted up fine...

IMG_0186.JPG

This is a stock Falcon with NVDI @Icky

IMG_0185.JPG

[exxos]

@Badwolf If my scope is not lying to me, I never see FPUCS going low. It is however connected back to the PLD fine. So no clue on that one unless the PLD itself has a blown IO :shrug:

Maybe the only way to prove it is if you could do a throwaway firmware which just connects 50mhz to FPUCS. Then I should see it on the FPU socket.

But could it be possible there is a address pin wonky on the PLD ? Though I would assume if that was the case alt-ram would screw up anyway or something.

[Badwolf]

@Badwolf If my scope is not lying to me, I never see FPUCS going low. It is however connected back to the PLD fine. So no clue on that one unless the PLD itself has a blown IO :shrug:

Interesting.

Try scoping the north side of LED5? That should go high on RESET, DSP access or FPUCS asserting. Should only be one of those happening by the time you get to Gembench.

BW

[DoG]

...I don't have the "working" version of MAPROM to hand ATM. I thought I'd posted it on another thread, but can't find it now...

Is this one?

[exxos]

Try scoping the north side of LED5? That should go high on RESET, DSP access or FPUCS asserting. Should only be one of those happening by the time you get to Gembench.

Okay so false alarm. The the scope was lying.

LED5 I saw pulsing. But on the FPU socket I did not.. So I set up a singleshot capture then I saw about 3 pulses. I checked DSACK (cannot remember if both pulsed or not) but there was activity there.

I have gone round all the FPU socket tabs and bend them all outwards and even re-solder the socket. Checked for shorts underneath.. Cannot find anything wrong with it all :lol: :roll:

So I don't know if @dml Has any ideas why the FPU test program would come a row of bombs on the first test.. Also the number it shows seems to be totally random all the time.

[dml]

So I don't know if @dml Has any ideas why the FPU test program would come a row of bombs on the first test.. Also the number it shows seems to be totally random all the time.

From what I remember, an FPU exception throws a ton of bombs - 11 or something (LINE-F exception). It can be looked up in the Atari docs.

This can happen if you use the FPU when its not installed, or if the FPU is installed but the pins have resistive contact, or if the FPU is cooked I suppose.

More subtle errors will only show in the test itself, on some operations. But a long row of bombs is a familiar outcome if the FPU is just not present or some pins not connected. When this happens it normally happens on the first FPU instruction encountered by the CPU.

[exxos]

Without the FPU it gives a row of bombs but no number. Very odd. Guess I am changing the socket then :lol: :roll:

[exxos]

Socket out.... Place your bets....

IMG_0188.JPG