DFB1 FPU experiment thread

[foft]

This thread is to track experiments to improve FPU stability on boards where it doesn't work out of the box.

e.g. adding extra capacitance, DSACK plumbing changes, FPU CS logic changes, clock changes, checking appropriate socket used etc!

[frank.lukas]

I understand not (not an expert) why is it so complicated ...

Atari TT and PAK68/2 and PAK68/3 have no problem with a asynchronous Line-A FPU

PAK68/2 (csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * /JP4 ;)

PAK68/3 ...
PAK 68/3, GAL U6: Adressdekoder, Atari ST

16-09-93 V6_STc1 Holger Zimmermann @ PE

                          ___  ___
                         |   \/   |
                    !vpa |1     24| VCC
                     fc0 |2     23| !jp3           Jumper J3: fpu_en
                     fc1 |3     22| !berr_20
                  !as_20 |4     21| !csp19
                     a21 |5     20| !rom
                     a20 |6     19| !fpucs
                     a17 |7     18| !word
                     a18 |8     17| !ciin
                     a16 |9     16| !dram
                     a19 |10    15| !avec
                     a22 |11    14| a23
                     GND |12    13| !berr_00
                         |________|

Code: Select all

%ID
   P6_ST
%TYP
   GAL20V8A
%PINS
 !vpa  fc0  fc1  !as_20  a21  a20  a17  a18  a16  a19  a22
 !berr_00  a23  !avec  !dram  !ciin  !word  !fpucs  !rom  !csp19
 !berr_20  !jp3
%LOGIC

 berr_20.OE = VCC;
 berr_20    = as_20 * fc1 * fc0 * !a19 * !a17                     'PMMU, BKPT
            + as_20 * fc1 * fc0 * !a19 *  a17 * !jp3            'FPU disabled
            + as_20 * berr_00;

 fpucs      = fc1 * fc0 * !a19 * !a18 *  a17 * !a16 * jp3;       'FPU enabled

 avec       = fc1 * fc0 * vpa;

 csp19      = fc1 * fc0 * !a19;

 dram       = !fc0 * !a23 * !a22
            + !fc1 * !a23 * !a22;

 rom        = a23 * a22 * a21 *  a20 *  a19 *  a18 * !a17           'TOS 1.04
            + a23 * a22 * a21 *  a20 *  a19 *  a18 * !a16           'TOS 1.04
            + a23 * a22 * a21 * !a20 * !a19;                        'TOS x.06

 word       = a23 * a22 * a21 *  a20 *  a19 *  a18 * !a17
            + a23 * a22 * a21 *  a20 *  a19 *  a18 * !a16
            + a23 * a22 * a21 * !a20 * !a19
            + !fc0 * !a23 * !a22
            + !fc1 * !a23 * !a22;

 !ciin      = a23 * a22 * a21 *  a20 *  a19 *  a18 * !a17                'ROM
            + a23 * a22 * a21 *  a20 *  a19 *  a18 * !a16                'ROM
            + a23 * a22 * a21 * !a20 * !a19                              'ROM
            + !fc0 * !a23 * !a22                                         'RAM
            + !fc1 * !a23 * !a22;                                        'RAM
%END

May be use a 16V8 GAL to generate fpucs without the CPLD Firmware ?

[Badwolf]

I understand not (not an expert) why is it so complicated ...

Neither do we Frank. That's kind of the problem...

BW

[foft]

I do have a bunch of GALs (and FPGAs) around so can try that too.

I was thinking of starting with just popping FPU_CS, FPUCLK, AS, FPU_DSACKn, CPU_DSACKn onto the logic analyzer to take a look. It's probably going to be easier to do that (without disturbing signals) with a slower clock. I guess I can remove the oscillator and drive the clock from a pll in one of my FPGAs floating around...

I wish I had signaltap II on the CPLD!

Unfortunately, other tasks call for now, so I might not progress so rapidly! French class tonight, work christmas party tomorrow etc.

I've no idea yet of the problem. I added some extra capacitors onto the power rails under one of the FPU sockets, with no change.
I'm using these sockets, hope those are good:
https://multimedia.3m.com/mws/media/358 ... ts2148.pdf

[Badwolf]

I was thinking of starting with just popping FPU_CS, FPUCLK, AS, FPU_DSACKn, CPU_DSACKn onto the logic analyzer to take a look. It's probably going to be easier to do that (without disturbing signals) with a slower clock. I guess I can remove the oscillator and drive the clock from a pll in one of my FPGAs floating around...

In the past I've just jumperwired XCPUCLK from the Falcon to the OSC IN.

Another option is to set OPTION2 (don't accelerate), remove R18 and join CPUCLK and FPUCLK to keep everything nicely in lockstep.

https://multimedia.3m.com/mws/media/358 ... ts2148.pdf

3M are probably the best generally available, so no drama there!

BTW, if you want a basic sanity check this is the fly-wire hack I mentioned to allow the onboard FPU socket to work. Obviously remove the external once first, but then you just need to jumper 030 DS to a pin on U62 (I use a protective resistor):

https://github.com/dh219/DFB/wiki/FPU#the-workaround

Your chips that fail some of the time can then be tested at 16MHz on the motherboard before being tested again at 16MHz on DFB1.

BW

[Rustynutt]

I understand not (not an expert) why is it so complicated ...

Neither do we Frank. That's kind of the problem...

BW

For years have kept this image bookmarked, running into similar problems on the stock board and overclocking FPU's.
Be nice to test theory someday. Believe the company is called WARWICK or WINSLOW in the UK.

PLCC to PGA FPU.jpg

[foft]

Sorry I am still here and interested, just caught up with some other stuff! I'll get a chance to try this in the next week or so I think.

[Badwolf]

Sorry I am still here and interested, just caught up with some other stuff! I'll get a chance to try this in the next week or so I think.

No worries. If you need any custom firmwares or want a hand modifying any of the verilog, I'll be eavesdropping :-)

BW

[Steve]

@Badwolf I was just reading the MAXI030 blog (a small 030 based system, project) The author was also having difficulty getting the FPU working properly, he had put the decoding on the rising edge of the clock to fix it.

Perhaps some of the details on his blog might help with the DFB1?

https://www.aslak.net/index.php/2022/01 ... d-maxi030/

(Incidentally I also wonder how EmuTOS would perform on this system)

[Badwolf]

Cheers, Steve.

Interesting read. He's working around limitations in his combinational logic it seems, but the fact it work even with a late CS signal should suggest sensitivity here isn't an issue.

No hard in Foft giving the same approach a go with one of his failing boards, mind.

BW